* [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Richard Weinberger, Wang Xiaoqiang,
Helge Deller, Mateusz Guzik, Alex Thorlton, Ben Segall,
John Stultz, Rik van Riel, Eric B Munson, Alexey Klimov,
Chen Gang, Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
Hello,
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
This patch series attempts to fix that by giving at least a nice starting
point from the highwater mark values of the resources in question.
I looked where each limit is checked and added a call to update the mark
nearby.
Example run of program from Documentation/accounting/getdelauys.c:
./getdelays -R -p `pidof smartd`
printing resource accounting
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
printing resource accounting
sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
In this example, smartd is running as a non-root user. The presented
values can be used as a starting point for giving new limits to the
service.
There's one problem with the patch 07/13, kernel initialization calls
create_worker() which seems to use different locking model or something:
[ 0.145410] =========================================================
[ 0.148000] [ INFO: possible irq lock inversion dependency detected ]
[ 0.148000] 4.7.0-rc7+ #155 Not tainted
[ 0.148000] ---------------------------------------------------------
[ 0.148000] swapper/0/1 just changed the state of lock:
[ 0.148000] (&(&(&sig->stats_lock)->lock)->rlock){+.....}, at: [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] but this lock was taken by another, HARDIRQ-safe lock in the past:
[ 0.148000] (&rq->lock){-.....}
and interrupts could create inverse lock ordering between them.
[ 0.148000]
[ 0.148000] other info that might help us debug this:
[ 0.148000] Possible interrupt unsafe locking scenario:
[ 0.148000]
[ 0.148000] CPU0 CPU1
[ 0.148000] ---- ----
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] local_irq_disable();
[ 0.148000] lock(&rq->lock);
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] <Interrupt>
[ 0.148000] lock(&rq->lock);
[ 0.148000]
[ 0.148000] *** DEADLOCK ***
[ 0.148000]
[ 0.148000] 2 locks held by swapper/0/1:
[ 0.148000] #0: (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff81092824>] get_online_cpus+0x24/0x70
[ 0.148000] #1: (smpboot_threads_lock){+.+.+.}, at: [<ffffffff810ba517>] smpboot_register_percpu_thread_cpumask+0x37/0xf0
[ 0.148000]
[ 0.148000] the shortest dependencies between 2nd lock and 1st lock:
[ 0.148000] -> (&rq->lock){-.....} ops: 181 {
[ 0.148000] IN-HARDIRQ-W at:
[ 0.148000] [<ffffffff810e8439>] __lock_acquire+0x6e9/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c3a41>] scheduler_tick+0x41/0xd0
[ 0.148000] [<ffffffff81110471>] update_process_times+0x51/0x60
[ 0.148000] [<ffffffff8111fa4f>] tick_periodic+0x2f/0xc0
[ 0.148000] [<ffffffff8111fb05>] tick_handle_periodic+0x25/0x70
[ 0.148000] [<ffffffff8101ebf5>] timer_interrupt+0x15/0x20
[ 0.148000] [<ffffffff810fc731>] handle_irq_event_percpu+0x41/0x320
[ 0.148000] [<ffffffff810fca49>] handle_irq_event+0x39/0x60
[ 0.148000] [<ffffffff810ffe08>] handle_level_irq+0x88/0x110
[ 0.148000] [<ffffffff8101e58a>] handle_irq+0x1a/0x30
[ 0.148000] [<ffffffff818d2281>] do_IRQ+0x61/0x120
[ 0.148000] [<ffffffff818d0949>] ret_from_intr+0x0/0x19
[ 0.148000] [<ffffffff810fe969>] __setup_irq+0x3f9/0x5e0
[ 0.148000] [<ffffffff810feb96>] setup_irq+0x46/0xa0
[ 0.148000] [<ffffffff821878e2>] setup_default_timer_irq+0x1e/0x20
[ 0.148000] [<ffffffff821878fb>] hpet_time_init+0x17/0x19
[ 0.148000] [<ffffffff821878bd>] x86_late_time_init+0xa/0x11
[ 0.148000] [<ffffffff82181ef9>] start_kernel+0x39d/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf82c>] _raw_spin_lock_irqsave+0x3c/0x50
[ 0.148000] [<ffffffff810bdc9d>] rq_attach_root+0x1d/0x100
[ 0.148000] [<ffffffff8219deab>] sched_init+0x2f5/0x44c
[ 0.148000] [<ffffffff82181d9d>] start_kernel+0x241/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f3ad0>] __key.60059+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000] -> (&(&(&sig->stats_lock)->lock)->rlock){+.....} ops: 2 {
[ 0.148000] HARDIRQ-ON-W at:
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f2190>] __key.55894+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000]
[ 0.148000] stack backtrace:
[ 0.148000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7+ #155
[ 0.148000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 0.148000] 0000000000000086 00000000aea03eae ffff88003de6ba60 ffffffff813cb2d5
[ 0.148000] ffffffff82d48e60 ffff88003de6bac0 ffff88003de6baa0 ffffffff811a6b05
[ 0.148000] ffff88003de647d8 ffff88003de647d8 ffff88003de64040 ffffffff81d531a7
[ 0.148000] Call Trace:
[ 0.148000] [<ffffffff813cb2d5>] dump_stack+0x67/0x92
[ 0.148000] [<ffffffff811a6b05>] print_irq_inversion_bug.part.38+0x1a4/0x1b0
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e6730>] ? check_usage_forwards+0x160/0x160
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e7a6d>] ? trace_hardirqs_on+0xd/0x10
[ 0.148000] [<ffffffff81104aad>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff821a168b>] ? pid_namespaces_init+0x40/0x40
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff8102c24d>] ? print_cpu_info+0x7d/0xe0
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [<ffffffff818c2060>] ? rest_init+0x130/0x130
In this v2, I tried to address all comments, thanks for reviews.
-Topi
Topi Miettinen (14):
resource limits: foundation for resource highwater tracking
resource limits: aggregate task highwater marks to cgroup level
resource limits: track highwater mark of file sizes
resource limits: track highwater mark of VM data segment
resource limits: track highwater mark of stack size
resource limits: track highwater mark of cores dumped
resource limits: track highwater mark of user processes
resource limits: track highwater mark of number of files
resource limits: track highwater mark of locked memory
resource limits: track highwater mark of address space size
resource limits: track highwater mark of number of pending signals
resource limits: track highwater mark of size of message queues
resource limits: track highwater mark of niceness
resource limits: track highwater mark of RT priority
Documentation/accounting/getdelays.c | 62 ++++++++++++++++++++++--
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 +
arch/powerpc/mm/mmu_context_iommu.c | 2 +
arch/x86/ia32/ia32_aout.c | 2 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 +
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +
drivers/vfio/vfio_iommu_type1.c | 5 ++
fs/attr.c | 2 +
fs/binfmt_aout.c | 2 +
fs/binfmt_flat.c | 2 +
fs/coredump.c | 11 +++--
fs/file.c | 4 ++
include/linux/cgroup-defs.h | 5 ++
include/linux/sched.h | 61 +++++++++++++++++++++++
include/linux/tsacct_kern.h | 3 ++
include/uapi/linux/cgroupstats.h | 3 ++
include/uapi/linux/taskstats.h | 10 +++-
ipc/mqueue.c | 1 +
kernel/bpf/syscall.c | 8 +++
kernel/cgroup.c | 78 ++++++++++++++++++++++++++++++
kernel/cred.c | 1 +
kernel/events/core.c | 1 +
kernel/fork.c | 2 +
kernel/sched/core.c | 6 +++
kernel/signal.c | 2 +
kernel/sys.c | 5 ++
kernel/taskstats.c | 4 ++
kernel/tsacct.c | 47 ++++++++++++++++++
mm/mlock.c | 8 +++
mm/mmap.c | 17 ++++++-
mm/mremap.c | 7 +++
36 files changed, 365 insertions(+), 9 deletions(-)
--
2.8.1
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Doug Ledford,
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit,
Alex Williamson, Alexander Viro, Tejun Heo, Li Zefan,
Johannes Weiner, Peter Zijlstra, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 Itanium PLATFORM,
open list:KERNEL VIRTUAL MACHINE KVM FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE KVM,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT,
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS VFS and infrastructure,
open list:CONTROL GROUP CGROUP,
open list:BPF Safe dynamic programs and tools,
open list:MEMORY MANAGEMENT
Hello,
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
This patch series attempts to fix that by giving at least a nice starting
point from the highwater mark values of the resources in question.
I looked where each limit is checked and added a call to update the mark
nearby.
Example run of program from Documentation/accounting/getdelauys.c:
./getdelays -R -p `pidof smartd`
printing resource accounting
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
printing resource accounting
sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
In this example, smartd is running as a non-root user. The presented
values can be used as a starting point for giving new limits to the
service.
There's one problem with the patch 07/13, kernel initialization calls
create_worker() which seems to use different locking model or something:
[ 0.145410] =========================================================
[ 0.148000] [ INFO: possible irq lock inversion dependency detected ]
[ 0.148000] 4.7.0-rc7+ #155 Not tainted
[ 0.148000] ---------------------------------------------------------
[ 0.148000] swapper/0/1 just changed the state of lock:
[ 0.148000] (&(&(&sig->stats_lock)->lock)->rlock){+.....}, at: [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] but this lock was taken by another, HARDIRQ-safe lock in the past:
[ 0.148000] (&rq->lock){-.....}
and interrupts could create inverse lock ordering between them.
[ 0.148000]
[ 0.148000] other info that might help us debug this:
[ 0.148000] Possible interrupt unsafe locking scenario:
[ 0.148000]
[ 0.148000] CPU0 CPU1
[ 0.148000] ---- ----
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] local_irq_disable();
[ 0.148000] lock(&rq->lock);
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] <Interrupt>
[ 0.148000] lock(&rq->lock);
[ 0.148000]
[ 0.148000] *** DEADLOCK ***
[ 0.148000]
[ 0.148000] 2 locks held by swapper/0/1:
[ 0.148000] #0: (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff81092824>] get_online_cpus+0x24/0x70
[ 0.148000] #1: (smpboot_threads_lock){+.+.+.}, at: [<ffffffff810ba517>] smpboot_register_percpu_thread_cpumask+0x37/0xf0
[ 0.148000]
[ 0.148000] the shortest dependencies between 2nd lock and 1st lock:
[ 0.148000] -> (&rq->lock){-.....} ops: 181 {
[ 0.148000] IN-HARDIRQ-W at:
[ 0.148000] [<ffffffff810e8439>] __lock_acquire+0x6e9/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c3a41>] scheduler_tick+0x41/0xd0
[ 0.148000] [<ffffffff81110471>] update_process_times+0x51/0x60
[ 0.148000] [<ffffffff8111fa4f>] tick_periodic+0x2f/0xc0
[ 0.148000] [<ffffffff8111fb05>] tick_handle_periodic+0x25/0x70
[ 0.148000] [<ffffffff8101ebf5>] timer_interrupt+0x15/0x20
[ 0.148000] [<ffffffff810fc731>] handle_irq_event_percpu+0x41/0x320
[ 0.148000] [<ffffffff810fca49>] handle_irq_event+0x39/0x60
[ 0.148000] [<ffffffff810ffe08>] handle_level_irq+0x88/0x110
[ 0.148000] [<ffffffff8101e58a>] handle_irq+0x1a/0x30
[ 0.148000] [<ffffffff818d2281>] do_IRQ+0x61/0x120
[ 0.148000] [<ffffffff818d0949>] ret_from_intr+0x0/0x19
[ 0.148000] [<ffffffff810fe969>] __setup_irq+0x3f9/0x5e0
[ 0.148000] [<ffffffff810feb96>] setup_irq+0x46/0xa0
[ 0.148000] [<ffffffff821878e2>] setup_default_timer_irq+0x1e/0x20
[ 0.148000] [<ffffffff821878fb>] hpet_time_init+0x17/0x19
[ 0.148000] [<ffffffff821878bd>] x86_late_time_init+0xa/0x11
[ 0.148000] [<ffffffff82181ef9>] start_kernel+0x39d/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf82c>] _raw_spin_lock_irqsave+0x3c/0x50
[ 0.148000] [<ffffffff810bdc9d>] rq_attach_root+0x1d/0x100
[ 0.148000] [<ffffffff8219deab>] sched_init+0x2f5/0x44c
[ 0.148000] [<ffffffff82181d9d>] start_kernel+0x241/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f3ad0>] __key.60059+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000] -> (&(&(&sig->stats_lock)->lock)->rlock){+.....} ops: 2 {
[ 0.148000] HARDIRQ-ON-W at:
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f2190>] __key.55894+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000]
[ 0.148000] stack backtrace:
[ 0.148000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7+ #155
[ 0.148000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 0.148000] 0000000000000086 00000000aea03eae ffff88003de6ba60 ffffffff813cb2d5
[ 0.148000] ffffffff82d48e60 ffff88003de6bac0 ffff88003de6baa0 ffffffff811a6b05
[ 0.148000] ffff88003de647d8 ffff88003de647d8 ffff88003de64040 ffffffff81d531a7
[ 0.148000] Call Trace:
[ 0.148000] [<ffffffff813cb2d5>] dump_stack+0x67/0x92
[ 0.148000] [<ffffffff811a6b05>] print_irq_inversion_bug.part.38+0x1a4/0x1b0
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e6730>] ? check_usage_forwards+0x160/0x160
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e7a6d>] ? trace_hardirqs_on+0xd/0x10
[ 0.148000] [<ffffffff81104aad>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff821a168b>] ? pid_namespaces_init+0x40/0x40
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff8102c24d>] ? print_cpu_info+0x7d/0xe0
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [<ffffffff818c2060>] ? rest_init+0x130/0x130
In this v2, I tried to address all comments, thanks for reviews.
-Topi
Topi Miettinen (14):
resource limits: foundation for resource highwater tracking
resource limits: aggregate task highwater marks to cgroup level
resource limits: track highwater mark of file sizes
resource limits: track highwater mark of VM data segment
resource limits: track highwater mark of stack size
resource limits: track highwater mark of cores dumped
resource limits: track highwater mark of user processes
resource limits: track highwater mark of number of files
resource limits: track highwater mark of locked memory
resource limits: track highwater mark of address space size
resource limits: track highwater mark of number of pending signals
resource limits: track highwater mark of size of message queues
resource limits: track highwater mark of niceness
resource limits: track highwater mark of RT priority
Documentation/accounting/getdelays.c | 62 ++++++++++++++++++++++--
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 +
arch/powerpc/mm/mmu_context_iommu.c | 2 +
arch/x86/ia32/ia32_aout.c | 2 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 +
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +
drivers/vfio/vfio_iommu_type1.c | 5 ++
fs/attr.c | 2 +
fs/binfmt_aout.c | 2 +
fs/binfmt_flat.c | 2 +
fs/coredump.c | 11 +++--
fs/file.c | 4 ++
include/linux/cgroup-defs.h | 5 ++
include/linux/sched.h | 61 +++++++++++++++++++++++
include/linux/tsacct_kern.h | 3 ++
include/uapi/linux/cgroupstats.h | 3 ++
include/uapi/linux/taskstats.h | 10 +++-
ipc/mqueue.c | 1 +
kernel/bpf/syscall.c | 8 +++
kernel/cgroup.c | 78 ++++++++++++++++++++++++++++++
kernel/cred.c | 1 +
kernel/events/core.c | 1 +
kernel/fork.c | 2 +
kernel/sched/core.c | 6 +++
kernel/signal.c | 2 +
kernel/sys.c | 5 ++
kernel/taskstats.c | 4 ++
kernel/tsacct.c | 47 ++++++++++++++++++
mm/mlock.c | 8 +++
mm/mmap.c | 17 ++++++-
mm/mremap.c | 7 +++
36 files changed, 365 insertions(+), 9 deletions(-)
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Richard Weinberger, Wang Xiaoqiang,
Helge Deller, Mateusz Guzik, Alex Thorlton, Ben Segall,
John Stultz, Rik van Riel, Eric B Munson, Alexey Klimov,
Chen Gang, Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
Hello,
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
This patch series attempts to fix that by giving at least a nice starting
point from the highwater mark values of the resources in question.
I looked where each limit is checked and added a call to update the mark
nearby.
Example run of program from Documentation/accounting/getdelauys.c:
./getdelays -R -p `pidof smartd`
printing resource accounting
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
printing resource accounting
sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
In this example, smartd is running as a non-root user. The presented
values can be used as a starting point for giving new limits to the
service.
There's one problem with the patch 07/13, kernel initialization calls
create_worker() which seems to use different locking model or something:
[ 0.145410] =========================================================
[ 0.148000] [ INFO: possible irq lock inversion dependency detected ]
[ 0.148000] 4.7.0-rc7+ #155 Not tainted
[ 0.148000] ---------------------------------------------------------
[ 0.148000] swapper/0/1 just changed the state of lock:
[ 0.148000] (&(&(&sig->stats_lock)->lock)->rlock){+.....}, at: [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] but this lock was taken by another, HARDIRQ-safe lock in the past:
[ 0.148000] (&rq->lock){-.....}
and interrupts could create inverse lock ordering between them.
[ 0.148000]
[ 0.148000] other info that might help us debug this:
[ 0.148000] Possible interrupt unsafe locking scenario:
[ 0.148000]
[ 0.148000] CPU0 CPU1
[ 0.148000] ---- ----
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] local_irq_disable();
[ 0.148000] lock(&rq->lock);
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] <Interrupt>
[ 0.148000] lock(&rq->lock);
[ 0.148000]
[ 0.148000] *** DEADLOCK ***
[ 0.148000]
[ 0.148000] 2 locks held by swapper/0/1:
[ 0.148000] #0: (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff81092824>] get_online_cpus+0x24/0x70
[ 0.148000] #1: (smpboot_threads_lock){+.+.+.}, at: [<ffffffff810ba517>] smpboot_register_percpu_thread_cpumask+0x37/0xf0
[ 0.148000]
[ 0.148000] the shortest dependencies between 2nd lock and 1st lock:
[ 0.148000] -> (&rq->lock){-.....} ops: 181 {
[ 0.148000] IN-HARDIRQ-W at:
[ 0.148000] [<ffffffff810e8439>] __lock_acquire+0x6e9/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c3a41>] scheduler_tick+0x41/0xd0
[ 0.148000] [<ffffffff81110471>] update_process_times+0x51/0x60
[ 0.148000] [<ffffffff8111fa4f>] tick_periodic+0x2f/0xc0
[ 0.148000] [<ffffffff8111fb05>] tick_handle_periodic+0x25/0x70
[ 0.148000] [<ffffffff8101ebf5>] timer_interrupt+0x15/0x20
[ 0.148000] [<ffffffff810fc731>] handle_irq_event_percpu+0x41/0x320
[ 0.148000] [<ffffffff810fca49>] handle_irq_event+0x39/0x60
[ 0.148000] [<ffffffff810ffe08>] handle_level_irq+0x88/0x110
[ 0.148000] [<ffffffff8101e58a>] handle_irq+0x1a/0x30
[ 0.148000] [<ffffffff818d2281>] do_IRQ+0x61/0x120
[ 0.148000] [<ffffffff818d0949>] ret_from_intr+0x0/0x19
[ 0.148000] [<ffffffff810fe969>] __setup_irq+0x3f9/0x5e0
[ 0.148000] [<ffffffff810feb96>] setup_irq+0x46/0xa0
[ 0.148000] [<ffffffff821878e2>] setup_default_timer_irq+0x1e/0x20
[ 0.148000] [<ffffffff821878fb>] hpet_time_init+0x17/0x19
[ 0.148000] [<ffffffff821878bd>] x86_late_time_init+0xa/0x11
[ 0.148000] [<ffffffff82181ef9>] start_kernel+0x39d/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf82c>] _raw_spin_lock_irqsave+0x3c/0x50
[ 0.148000] [<ffffffff810bdc9d>] rq_attach_root+0x1d/0x100
[ 0.148000] [<ffffffff8219deab>] sched_init+0x2f5/0x44c
[ 0.148000] [<ffffffff82181d9d>] start_kernel+0x241/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f3ad0>] __key.60059+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000] -> (&(&(&sig->stats_lock)->lock)->rlock){+.....} ops: 2 {
[ 0.148000] HARDIRQ-ON-W at:
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f2190>] __key.55894+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000]
[ 0.148000] stack backtrace:
[ 0.148000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7+ #155
[ 0.148000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 0.148000] 0000000000000086 00000000aea03eae ffff88003de6ba60 ffffffff813cb2d5
[ 0.148000] ffffffff82d48e60 ffff88003de6bac0 ffff88003de6baa0 ffffffff811a6b05
[ 0.148000] ffff88003de647d8 ffff88003de647d8 ffff88003de64040 ffffffff81d531a7
[ 0.148000] Call Trace:
[ 0.148000] [<ffffffff813cb2d5>] dump_stack+0x67/0x92
[ 0.148000] [<ffffffff811a6b05>] print_irq_inversion_bug.part.38+0x1a4/0x1b0
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e6730>] ? check_usage_forwards+0x160/0x160
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e7a6d>] ? trace_hardirqs_on+0xd/0x10
[ 0.148000] [<ffffffff81104aad>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff821a168b>] ? pid_namespaces_init+0x40/0x40
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff8102c24d>] ? print_cpu_info+0x7d/0xe0
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [<ffffffff818c2060>] ? rest_init+0x130/0x130
In this v2, I tried to address all comments, thanks for reviews.
-Topi
Topi Miettinen (14):
resource limits: foundation for resource highwater tracking
resource limits: aggregate task highwater marks to cgroup level
resource limits: track highwater mark of file sizes
resource limits: track highwater mark of VM data segment
resource limits: track highwater mark of stack size
resource limits: track highwater mark of cores dumped
resource limits: track highwater mark of user processes
resource limits: track highwater mark of number of files
resource limits: track highwater mark of locked memory
resource limits: track highwater mark of address space size
resource limits: track highwater mark of number of pending signals
resource limits: track highwater mark of size of message queues
resource limits: track highwater mark of niceness
resource limits: track highwater mark of RT priority
Documentation/accounting/getdelays.c | 62 ++++++++++++++++++++++--
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 +
arch/powerpc/mm/mmu_context_iommu.c | 2 +
arch/x86/ia32/ia32_aout.c | 2 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 +
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +
drivers/vfio/vfio_iommu_type1.c | 5 ++
fs/attr.c | 2 +
fs/binfmt_aout.c | 2 +
fs/binfmt_flat.c | 2 +
fs/coredump.c | 11 +++--
fs/file.c | 4 ++
include/linux/cgroup-defs.h | 5 ++
include/linux/sched.h | 61 +++++++++++++++++++++++
include/linux/tsacct_kern.h | 3 ++
include/uapi/linux/cgroupstats.h | 3 ++
include/uapi/linux/taskstats.h | 10 +++-
ipc/mqueue.c | 1 +
kernel/bpf/syscall.c | 8 +++
kernel/cgroup.c | 78 ++++++++++++++++++++++++++++++
kernel/cred.c | 1 +
kernel/events/core.c | 1 +
kernel/fork.c | 2 +
kernel/sched/core.c | 6 +++
kernel/signal.c | 2 +
kernel/sys.c | 5 ++
kernel/taskstats.c | 4 ++
kernel/tsacct.c | 47 ++++++++++++++++++
mm/mlock.c | 8 +++
mm/mmap.c | 17 ++++++-
mm/mremap.c | 7 +++
36 files changed, 365 insertions(+), 9 deletions(-)
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell
Hello,
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
This patch series attempts to fix that by giving at least a nice starting
point from the highwater mark values of the resources in question.
I looked where each limit is checked and added a call to update the mark
nearby.
Example run of program from Documentation/accounting/getdelauys.c:
./getdelays -R -p `pidof smartd`
printing resource accounting
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
printing resource accounting
sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
In this example, smartd is running as a non-root user. The presented
values can be used as a starting point for giving new limits to the
service.
There's one problem with the patch 07/13, kernel initialization calls
create_worker() which seems to use different locking model or something:
[ 0.145410] =========================================================
[ 0.148000] [ INFO: possible irq lock inversion dependency detected ]
[ 0.148000] 4.7.0-rc7+ #155 Not tainted
[ 0.148000] ---------------------------------------------------------
[ 0.148000] swapper/0/1 just changed the state of lock:
[ 0.148000] (&(&(&sig->stats_lock)->lock)->rlock){+.....}, at: [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] but this lock was taken by another, HARDIRQ-safe lock in the past:
[ 0.148000] (&rq->lock){-.....}
and interrupts could create inverse lock ordering between them.
[ 0.148000]
[ 0.148000] other info that might help us debug this:
[ 0.148000] Possible interrupt unsafe locking scenario:
[ 0.148000]
[ 0.148000] CPU0 CPU1
[ 0.148000] ---- ----
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] local_irq_disable();
[ 0.148000] lock(&rq->lock);
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] <Interrupt>
[ 0.148000] lock(&rq->lock);
[ 0.148000]
[ 0.148000] *** DEADLOCK ***
[ 0.148000]
[ 0.148000] 2 locks held by swapper/0/1:
[ 0.148000] #0: (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff81092824>] get_online_cpus+0x24/0x70
[ 0.148000] #1: (smpboot_threads_lock){+.+.+.}, at: [<ffffffff810ba517>] smpboot_register_percpu_thread_cpumask+0x37/0xf0
[ 0.148000]
[ 0.148000] the shortest dependencies between 2nd lock and 1st lock:
[ 0.148000] -> (&rq->lock){-.....} ops: 181 {
[ 0.148000] IN-HARDIRQ-W at:
[ 0.148000] [<ffffffff810e8439>] __lock_acquire+0x6e9/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c3a41>] scheduler_tick+0x41/0xd0
[ 0.148000] [<ffffffff81110471>] update_process_times+0x51/0x60
[ 0.148000] [<ffffffff8111fa4f>] tick_periodic+0x2f/0xc0
[ 0.148000] [<ffffffff8111fb05>] tick_handle_periodic+0x25/0x70
[ 0.148000] [<ffffffff8101ebf5>] timer_interrupt+0x15/0x20
[ 0.148000] [<ffffffff810fc731>] handle_irq_event_percpu+0x41/0x320
[ 0.148000] [<ffffffff810fca49>] handle_irq_event+0x39/0x60
[ 0.148000] [<ffffffff810ffe08>] handle_level_irq+0x88/0x110
[ 0.148000] [<ffffffff8101e58a>] handle_irq+0x1a/0x30
[ 0.148000] [<ffffffff818d2281>] do_IRQ+0x61/0x120
[ 0.148000] [<ffffffff818d0949>] ret_from_intr+0x0/0x19
[ 0.148000] [<ffffffff810fe969>] __setup_irq+0x3f9/0x5e0
[ 0.148000] [<ffffffff810feb96>] setup_irq+0x46/0xa0
[ 0.148000] [<ffffffff821878e2>] setup_default_timer_irq+0x1e/0x20
[ 0.148000] [<ffffffff821878fb>] hpet_time_init+0x17/0x19
[ 0.148000] [<ffffffff821878bd>] x86_late_time_init+0xa/0x11
[ 0.148000] [<ffffffff82181ef9>] start_kernel+0x39d/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf82c>] _raw_spin_lock_irqsave+0x3c/0x50
[ 0.148000] [<ffffffff810bdc9d>] rq_attach_root+0x1d/0x100
[ 0.148000] [<ffffffff8219deab>] sched_init+0x2f5/0x44c
[ 0.148000] [<ffffffff82181d9d>] start_kernel+0x241/0x465
[ 0.148000] [<ffffffff82181294>] x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>] x86_64_start_kernel+0x178/0x18b
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f3ad0>] __key.60059+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000] -> (&(&(&sig->stats_lock)->lock)->rlock){+.....} ops: 2 {
[ 0.148000] HARDIRQ-ON-W at:
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>] __lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f2190>] __key.55894+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000]
[ 0.148000]
[ 0.148000] stack backtrace:
[ 0.148000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7+ #155
[ 0.148000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 0.148000] 0000000000000086 00000000aea03eae ffff88003de6ba60 ffffffff813cb2d5
[ 0.148000] ffffffff82d48e60 ffff88003de6bac0 ffff88003de6baa0 ffffffff811a6b05
[ 0.148000] ffff88003de647d8 ffff88003de647d8 ffff88003de64040 ffffffff81d531a7
[ 0.148000] Call Trace:
[ 0.148000] [<ffffffff813cb2d5>] dump_stack+0x67/0x92
[ 0.148000] [<ffffffff811a6b05>] print_irq_inversion_bug.part.38+0x1a4/0x1b0
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e6730>] ? check_usage_forwards+0x160/0x160
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e7a6d>] ? trace_hardirqs_on+0xd/0x10
[ 0.148000] [<ffffffff81104aad>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>] __smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>] smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff821a168b>] ? pid_namespaces_init+0x40/0x40
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff8102c24d>] ? print_cpu_info+0x7d/0xe0
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [<ffffffff818c2060>] ? rest_init+0x130/0x130
In this v2, I tried to address all comments, thanks for reviews.
-Topi
Topi Miettinen (14):
resource limits: foundation for resource highwater tracking
resource limits: aggregate task highwater marks to cgroup level
resource limits: track highwater mark of file sizes
resource limits: track highwater mark of VM data segment
resource limits: track highwater mark of stack size
resource limits: track highwater mark of cores dumped
resource limits: track highwater mark of user processes
resource limits: track highwater mark of number of files
resource limits: track highwater mark of locked memory
resource limits: track highwater mark of address space size
resource limits: track highwater mark of number of pending signals
resource limits: track highwater mark of size of message queues
resource limits: track highwater mark of niceness
resource limits: track highwater mark of RT priority
Documentation/accounting/getdelays.c | 62 ++++++++++++++++++++++--
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 +
arch/powerpc/mm/mmu_context_iommu.c | 2 +
arch/x86/ia32/ia32_aout.c | 2 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 +
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +
drivers/vfio/vfio_iommu_type1.c | 5 ++
fs/attr.c | 2 +
fs/binfmt_aout.c | 2 +
fs/binfmt_flat.c | 2 +
fs/coredump.c | 11 +++--
fs/file.c | 4 ++
include/linux/cgroup-defs.h | 5 ++
include/linux/sched.h | 61 +++++++++++++++++++++++
include/linux/tsacct_kern.h | 3 ++
include/uapi/linux/cgroupstats.h | 3 ++
include/uapi/linux/taskstats.h | 10 +++-
ipc/mqueue.c | 1 +
kernel/bpf/syscall.c | 8 +++
kernel/cgroup.c | 78 ++++++++++++++++++++++++++++++
kernel/cred.c | 1 +
kernel/events/core.c | 1 +
kernel/fork.c | 2 +
kernel/sched/core.c | 6 +++
kernel/signal.c | 2 +
kernel/sys.c | 5 ++
kernel/taskstats.c | 4 ++
kernel/tsacct.c | 47 ++++++++++++++++++
mm/mlock.c | 8 +++
mm/mmap.c | 17 ++++++-
mm/mremap.c | 7 +++
36 files changed, 365 insertions(+), 9 deletions(-)
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread* [PATCH 01/14] resource limits: foundation for resource highwater tracking
2016-07-15 10:35 ` Topi Miettinen
` (3 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
2016-07-15 12:12 ` kbuild test robot
2016-07-15 12:49 ` Nicolas Dichtel
-1 siblings, 2 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Ingo Molnar, Peter Zijlstra,
Balbir Singh, David S. Miller, Nicolas Dichtel, Markus Elfring,
Thomas Gleixner, Rik van Riel, open list:DOCUMENTATION
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
Prepare a foundation for resource highwater tracking.
The collected highwater marks for the resources can be seen using
taskstats netlink interface.
This depends on CONFIG_TASK_XACCT.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
Documentation/accounting/getdelays.c | 52 +++++++++++++++++++++++++++++++++---
include/linux/sched.h | 31 +++++++++++++++++++++
include/linux/tsacct_kern.h | 3 +++
include/uapi/linux/taskstats.h | 10 ++++++-
kernel/taskstats.c | 4 +++
kernel/tsacct.c | 26 ++++++++++++++++++
6 files changed, 122 insertions(+), 4 deletions(-)
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index b5ca536..489f1b7 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -8,7 +8,7 @@
* Copyright (c) Jay Lan, SGI. 2006
*
* Compile with
- * gcc -I/usr/src/linux/include getdelays.c -o getdelays
+ * gcc -I/usr/src/linux getdelays.c -o getdelays
*/
#include <stdio.h>
@@ -22,10 +22,11 @@
#include <sys/stat.h>
#include <sys/socket.h>
#include <sys/wait.h>
+#include <sys/resource.h>
#include <signal.h>
#include <linux/genetlink.h>
-#include <linux/taskstats.h>
+#include "include/uapi/linux/taskstats.h"
#include <linux/cgroupstats.h>
/*
@@ -50,6 +51,7 @@ char name[100];
int dbg;
int print_delays;
int print_io_accounting;
+int print_resource_accounting;
int print_task_context_switch_counts;
#define PRINTF(fmt, arg...) { \
@@ -63,6 +65,8 @@ int print_task_context_switch_counts;
/* Maximum number of cpus expected to be specified in a cpumask */
#define MAX_CPUS 32
+#define TASKSTATS_VERSION_WITH_RESOURCE 9
+
struct msgtemplate {
struct nlmsghdr n;
struct genlmsghdr g;
@@ -77,6 +81,7 @@ static void usage(void)
"[-m cpumask] [-t tgid] [-p pid]\n");
fprintf(stderr, " -d: print delayacct stats\n");
fprintf(stderr, " -i: print IO accounting (works only with -p)\n");
+ fprintf(stderr, " -R: print resource accounting stats\n");
fprintf(stderr, " -l: listen forever\n");
fprintf(stderr, " -v: debug on\n");
fprintf(stderr, " -C: container path\n");
@@ -232,6 +237,25 @@ static void task_context_switch_counts(struct taskstats *t)
(unsigned long long)t->nvcsw, (unsigned long long)t->nivcsw);
}
+static const char *const rlimit_names[] = {
+ [RLIMIT_CPU] = "RLIMIT_CPU",
+ [RLIMIT_FSIZE] = "RLIMIT_FSIZE",
+ [RLIMIT_DATA] = "RLIMIT_DATA",
+ [RLIMIT_STACK] = "RLIMIT_STACK",
+ [RLIMIT_CORE] = "RLIMIT_CORE",
+ [RLIMIT_RSS] = "RLIMIT_RSS",
+ [RLIMIT_NPROC] = "RLIMIT_NPROC",
+ [RLIMIT_NOFILE] = "RLIMIT_NOFILE",
+ [RLIMIT_MEMLOCK] = "RLIMIT_MEMLOCK",
+ [RLIMIT_AS] = "RLIMIT_AS",
+ [RLIMIT_LOCKS] = "RLIMIT_LOCKS",
+ [RLIMIT_SIGPENDING] = "RLIMIT_SIGPENDING",
+ [RLIMIT_MSGQUEUE] = "RLIMIT_MSGQUEUE",
+ [RLIMIT_NICE] = "RLIMIT_NICE",
+ [RLIMIT_RTPRIO] = "RLIMIT_RTPRIO",
+ [RLIMIT_RTTIME] = "RLIMIT_RTTIME",
+};
+
static void print_cgroupstats(struct cgroupstats *c)
{
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
@@ -252,6 +276,22 @@ static void print_ioacct(struct taskstats *t)
(unsigned long long)t->cancelled_write_bytes);
}
+static void print_racct(const struct taskstats *t)
+{
+ int i;
+
+ if (t->version < TASKSTATS_VERSION_WITH_RESOURCE) {
+ printf("kernel too old (%d < %d)\n", t->version,
+ TASKSTATS_VERSION_WITH_RESOURCE);
+ return;
+ }
+
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ printf("%s=%llu\n",
+ rlimit_names[i],
+ (unsigned long long)t->resource_hiwater[i]);
+}
+
int main(int argc, char *argv[])
{
int c, rc, rep_len, aggr_len, len2;
@@ -280,7 +320,7 @@ int main(int argc, char *argv[])
struct msgtemplate msg;
while (!forking) {
- c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:");
+ c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:R");
if (c < 0)
break;
@@ -297,6 +337,10 @@ int main(int argc, char *argv[])
printf("printing task/process context switch rates\n");
print_task_context_switch_counts = 1;
break;
+ case 'R':
+ printf("printing resource accounting\n");
+ print_resource_accounting = 1;
+ break;
case 'C':
containerset = 1;
containerpath = optarg;
@@ -497,6 +541,8 @@ int main(int argc, char *argv[])
print_ioacct((struct taskstats *) NLA_DATA(na));
if (print_task_context_switch_counts)
task_context_switch_counts((struct taskstats *) NLA_DATA(na));
+ if (print_resource_accounting)
+ print_racct((struct taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
err(1,"write error\n");
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 253538f..e4d7482 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -763,6 +763,9 @@ struct signal_struct {
unsigned long inblock, oublock, cinblock, coublock;
unsigned long maxrss, cmaxrss;
struct task_io_accounting ioac;
+#ifdef CONFIG_TASK_XACCT
+ unsigned long resource_highwatermark[RLIM_NLIMITS];
+#endif
/*
* Cumulative ns of schedule CPU time fo dead threads in the
@@ -3323,6 +3326,24 @@ static inline void inc_syscw(struct task_struct *tsk)
{
tsk->ioac.syscw++;
}
+
+static inline void task_update_resource_highwatermark(struct task_struct *tsk,
+ unsigned int limit,
+ unsigned long r)
+{
+ struct signal_struct *sig = tsk->signal;
+
+ write_seqlock(&sig->stats_lock);
+ if ((sig->resource_highwatermark[limit]) < r)
+ sig->resource_highwatermark[limit] = r;
+ write_sequnlock(&sig->stats_lock);
+}
+
+static inline void update_resource_highwatermark(unsigned int limit,
+ unsigned long r)
+{
+ task_update_resource_highwatermark(current, limit, r);
+}
#else
static inline void add_rchar(struct task_struct *tsk, ssize_t amt)
{
@@ -3339,6 +3360,16 @@ static inline void inc_syscr(struct task_struct *tsk)
static inline void inc_syscw(struct task_struct *tsk)
{
}
+static inline void task_update_resource_highwatermark(struct task_struct *tsk,
+ unsigned int limit,
+ unsigned long r)
+{
+}
+
+static inline void update_resource_highwatermark(unsigned int limit,
+ unsigned long r)
+{
+}
#endif
#ifndef TASK_SIZE_OF
diff --git a/include/linux/tsacct_kern.h b/include/linux/tsacct_kern.h
index 3251965..bcf1301 100644
--- a/include/linux/tsacct_kern.h
+++ b/include/linux/tsacct_kern.h
@@ -25,6 +25,7 @@ extern void xacct_add_tsk(struct taskstats *stats, struct task_struct *p);
extern void acct_update_integrals(struct task_struct *tsk);
extern void acct_account_cputime(struct task_struct *tsk);
extern void acct_clear_integrals(struct task_struct *tsk);
+extern void racct_add_tsk(struct taskstats *stats, struct task_struct *tsk);
#else
static inline void xacct_add_tsk(struct taskstats *stats, struct task_struct *p)
{}
@@ -34,6 +35,8 @@ static inline void acct_account_cputime(struct task_struct *tsk)
{}
static inline void acct_clear_integrals(struct task_struct *tsk)
{}
+static inline void racct_add_tsk(struct taskstats *stats, struct task_struct *p)
+{}
#endif /* CONFIG_TASK_XACCT */
#endif
diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
index 2466e55..8c65194 100644
--- a/include/uapi/linux/taskstats.h
+++ b/include/uapi/linux/taskstats.h
@@ -33,7 +33,7 @@
*/
-#define TASKSTATS_VERSION 8
+#define TASKSTATS_VERSION 9
#define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
* in linux/sched.h */
@@ -163,6 +163,14 @@ struct taskstats {
/* Delay waiting for memory reclaim */
__u64 freepages_count;
__u64 freepages_delay_total;
+ /* Per-task storage I/O accounting ends */
+
+#define TASKSTATS_HAS_LIMIT_ACCOUNTING
+ /* Per-task resource accounting starts */
+ __u64 resource_hiwater[RLIM_NLIMITS]; /* high-watermark of
+ RLIMIT
+ resources */
+ /* Per-task resource accounting ends */
};
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index b3f05ee..9a03e6b 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -17,6 +17,7 @@
*/
#include <linux/kernel.h>
+#include <linux/resource.h>
#include <linux/taskstats_kern.h>
#include <linux/tsacct_kern.h>
#include <linux/delayacct.h>
@@ -188,6 +189,9 @@ static void fill_stats(struct user_namespace *user_ns,
/* fill in extended acct fields */
xacct_add_tsk(stats, tsk);
+
+ /* fill in resource acct fields */
+ racct_add_tsk(stats, tsk);
}
static int fill_stats_for_pid(pid_t pid, struct taskstats *stats)
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index f8e26ab..231bae3 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -183,4 +183,30 @@ void acct_clear_integrals(struct task_struct *tsk)
tsk->acct_rss_mem1 = 0;
tsk->acct_vm_mem1 = 0;
}
+
+/*
+ * fill in resource accounting fields
+ */
+void racct_add_tsk(struct taskstats *stats, struct task_struct *tsk)
+{
+ struct signal_struct *sig = tsk->signal;
+ int i;
+ unsigned int seq, nextseq;
+ unsigned long flags;
+
+ rcu_read_lock();
+ /* Attempt a lockless read on the first round. */
+ nextseq = 0;
+ do {
+ seq = nextseq;
+ flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ stats->resource_hiwater[i] = (__u64)sig->resource_highwatermark[i];
+
+ /* If lockless access failed, take the lock. */
+ nextseq = 1;
+ } while (need_seqretry(&sig->stats_lock, seq));
+ done_seqretry_irqrestore(&sig->stats_lock, seq, flags);
+ rcu_read_unlock();
+}
#endif
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH 01/14] resource limits: foundation for resource highwater tracking
2016-07-15 10:35 ` [PATCH 01/14] resource limits: foundation for resource highwater tracking Topi Miettinen
@ 2016-07-15 12:12 ` kbuild test robot
2016-07-15 12:49 ` Nicolas Dichtel
1 sibling, 0 replies; 95+ messages in thread
From: kbuild test robot @ 2016-07-15 12:12 UTC (permalink / raw)
To: Topi Miettinen
Cc: kbuild-all, linux-kernel, Topi Miettinen, Jonathan Corbet,
Ingo Molnar, Peter Zijlstra, Balbir Singh, David S. Miller,
Nicolas Dichtel, Markus Elfring, Thomas Gleixner, Rik van Riel,
open list:DOCUMENTATION
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
Hi,
[auto build test ERROR on v4.7-rc7]
[also build test ERROR on next-20160715]
[cannot apply to tip/sched/core rdma/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Topi-Miettinen/Present-useful-limits-to-user-v2/20160715-194333
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> Documentation/accounting/getdelays.c:29:42: fatal error: include/uapi/linux/taskstats.h: No such file or directory
#include "include/uapi/linux/taskstats.h"
^
compilation terminated.
vim +29 Documentation/accounting/getdelays.c
23 #include <sys/socket.h>
24 #include <sys/wait.h>
25 #include <sys/resource.h>
26 #include <signal.h>
27
28 #include <linux/genetlink.h>
> 29 #include "include/uapi/linux/taskstats.h"
30 #include <linux/cgroupstats.h>
31
32 /*
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6334 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 01/14] resource limits: foundation for resource highwater tracking
2016-07-15 10:35 ` [PATCH 01/14] resource limits: foundation for resource highwater tracking Topi Miettinen
2016-07-15 12:12 ` kbuild test robot
@ 2016-07-15 12:49 ` Nicolas Dichtel
2016-07-15 16:27 ` Topi Miettinen
1 sibling, 1 reply; 95+ messages in thread
From: Nicolas Dichtel @ 2016-07-15 12:49 UTC (permalink / raw)
To: Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Ingo Molnar, Peter Zijlstra, Balbir Singh,
David S. Miller, Markus Elfring, Thomas Gleixner, Rik van Riel,
open list:DOCUMENTATION
Le 15/07/2016 12:35, Topi Miettinen a écrit :
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> Prepare a foundation for resource highwater tracking.
>
> The collected highwater marks for the resources can be seen using
> taskstats netlink interface.
>
> This depends on CONFIG_TASK_XACCT.
>
> Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
> ---
[snip]
> @@ -63,6 +65,8 @@ int print_task_context_switch_counts;
> /* Maximum number of cpus expected to be specified in a cpumask */
> #define MAX_CPUS 32
>
> +#define TASKSTATS_VERSION_WITH_RESOURCE 9
> +
> struct msgtemplate {
> struct nlmsghdr n;
> struct genlmsghdr g;
[snip]
> @@ -252,6 +276,22 @@ static void print_ioacct(struct taskstats *t)
> (unsigned long long)t->cancelled_write_bytes);
> }
>
> +static void print_racct(const struct taskstats *t)
> +{
> + int i;
> +
> + if (t->version < TASKSTATS_VERSION_WITH_RESOURCE) {
> + printf("kernel too old (%d < %d)\n", t->version,
> + TASKSTATS_VERSION_WITH_RESOURCE);
> + return;
> + }
[snip]
> diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
> index 2466e55..8c65194 100644
> --- a/include/uapi/linux/taskstats.h
> +++ b/include/uapi/linux/taskstats.h
> @@ -33,7 +33,7 @@
> */
>
>
> -#define TASKSTATS_VERSION 8
> +#define TASKSTATS_VERSION 9
> #define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
> * in linux/sched.h */
>
> @@ -163,6 +163,14 @@ struct taskstats {
> /* Delay waiting for memory reclaim */
> __u64 freepages_count;
> __u64 freepages_delay_total;
> + /* Per-task storage I/O accounting ends */
> +
> +#define TASKSTATS_HAS_LIMIT_ACCOUNTING
> + /* Per-task resource accounting starts */
> + __u64 resource_hiwater[RLIM_NLIMITS]; /* high-watermark of
> + RLIMIT
> + resources */
> + /* Per-task resource accounting ends */
> };
Why playing with version number? It complexifies the (userland) code and
existing applications break when the kernel is updated.
Goal of netlink is to be easily extensible. By adding a new attribute, existing
userspace tools won't break.
Regards,
Nicolas
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 01/14] resource limits: foundation for resource highwater tracking
2016-07-15 12:49 ` Nicolas Dichtel
@ 2016-07-15 16:27 ` Topi Miettinen
2016-07-15 17:57 ` Nicolas Dichtel
0 siblings, 1 reply; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:27 UTC (permalink / raw)
To: nicolas.dichtel, linux-kernel
Cc: Jonathan Corbet, Ingo Molnar, Peter Zijlstra, Balbir Singh,
David S. Miller, Markus Elfring, Thomas Gleixner, Rik van Riel,
open list:DOCUMENTATION
On 07/15/16 12:49, Nicolas Dichtel wrote:
> Le 15/07/2016 12:35, Topi Miettinen a écrit :
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> Prepare a foundation for resource highwater tracking.
>>
>> The collected highwater marks for the resources can be seen using
>> taskstats netlink interface.
>>
>> This depends on CONFIG_TASK_XACCT.
>>
>> Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
>> ---
> [snip]
>> @@ -63,6 +65,8 @@ int print_task_context_switch_counts;
>> /* Maximum number of cpus expected to be specified in a cpumask */
>> #define MAX_CPUS 32
>>
>> +#define TASKSTATS_VERSION_WITH_RESOURCE 9
>> +
>> struct msgtemplate {
>> struct nlmsghdr n;
>> struct genlmsghdr g;
> [snip]
>> @@ -252,6 +276,22 @@ static void print_ioacct(struct taskstats *t)
>> (unsigned long long)t->cancelled_write_bytes);
>> }
>>
>> +static void print_racct(const struct taskstats *t)
>> +{
>> + int i;
>> +
>> + if (t->version < TASKSTATS_VERSION_WITH_RESOURCE) {
>> + printf("kernel too old (%d < %d)\n", t->version,
>> + TASKSTATS_VERSION_WITH_RESOURCE);
>> + return;
>> + }
>
> [snip]
>> diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
>> index 2466e55..8c65194 100644
>> --- a/include/uapi/linux/taskstats.h
>> +++ b/include/uapi/linux/taskstats.h
>> @@ -33,7 +33,7 @@
>> */
>>
>>
>> -#define TASKSTATS_VERSION 8
>> +#define TASKSTATS_VERSION 9
>> #define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
>> * in linux/sched.h */
>>
>> @@ -163,6 +163,14 @@ struct taskstats {
>> /* Delay waiting for memory reclaim */
>> __u64 freepages_count;
>> __u64 freepages_delay_total;
>> + /* Per-task storage I/O accounting ends */
>> +
>> +#define TASKSTATS_HAS_LIMIT_ACCOUNTING
>> + /* Per-task resource accounting starts */
>> + __u64 resource_hiwater[RLIM_NLIMITS]; /* high-watermark of
>> + RLIMIT
>> + resources */
>> + /* Per-task resource accounting ends */
>> };
> Why playing with version number? It complexifies the (userland) code and
> existing applications break when the kernel is updated.
> Goal of netlink is to be easily extensible. By adding a new attribute, existing
> userspace tools won't break.
I just followed this text in taskstats.h. Does that give wrong advice?
* The struct is versioned. Newer versions should only add fields to
* the bottom of the struct to maintain backward compatibility.
*
*
* To add new fields
* a) bump up TASKSTATS_VERSION
* b) add comment indicating new version number at end of struct
* c) add new fields after version comment; maintain 64-bit alignment
-Topi
>
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 01/14] resource limits: foundation for resource highwater tracking
2016-07-15 16:27 ` Topi Miettinen
@ 2016-07-15 17:57 ` Nicolas Dichtel
0 siblings, 0 replies; 95+ messages in thread
From: Nicolas Dichtel @ 2016-07-15 17:57 UTC (permalink / raw)
To: Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Ingo Molnar, Peter Zijlstra, Balbir Singh,
David S. Miller, Markus Elfring, Thomas Gleixner, Rik van Riel,
open list:DOCUMENTATION
Le 15/07/2016 18:27, Topi Miettinen a écrit :
[snip]
>> Why playing with version number? It complexifies the (userland) code and
>> existing applications break when the kernel is updated.
>> Goal of netlink is to be easily extensible. By adding a new attribute, existing
>> userspace tools won't break.
>
> I just followed this text in taskstats.h. Does that give wrong advice?
>
> * The struct is versioned. Newer versions should only add fields to
> * the bottom of the struct to maintain backward compatibility.
> *
> *
> * To add new fields
> * a) bump up TASKSTATS_VERSION
> * b) add comment indicating new version number at end of struct
> * c) add new fields after version comment; maintain 64-bit alignment
I don't know taskstats well, but that is not how netlink works. There is no need
to manage a version with netlink, just add new attributes.
Regards,
Nicolas
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-15 10:35 ` Topi Miettinen
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tejun Heo, Li Zefan,
Johannes Weiner, Markus Elfring, David S. Miller,
Nicolas Dichtel, open list:DOCUMENTATION,
open list:CONTROL GROUP (CGROUP)
Collect resource usage highwater marks of a task to cgroup
statistics when the task exits.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
Documentation/accounting/getdelays.c | 10 ++++++-
include/linux/cgroup-defs.h | 5 ++++
include/uapi/linux/cgroupstats.h | 3 ++
kernel/cgroup.c | 55 ++++++++++++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index 489f1b7..7c86279 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -27,7 +27,7 @@
#include <linux/genetlink.h>
#include "include/uapi/linux/taskstats.h"
-#include <linux/cgroupstats.h>
+#include "include/uapi/linux/cgroupstats.h"
/*
* Generic macros for dealing with netlink sockets. Might be duplicated
@@ -258,12 +258,20 @@ static const char *const rlimit_names[] = {
static void print_cgroupstats(struct cgroupstats *c)
{
+ int i;
+
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
"uninterruptible %llu\n", (unsigned long long)c->nr_sleeping,
(unsigned long long)c->nr_io_wait,
(unsigned long long)c->nr_running,
(unsigned long long)c->nr_stopped,
(unsigned long long)c->nr_uninterruptible);
+
+ if (print_resource_accounting)
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ printf("%s=%llu\n",
+ rlimit_names[i],
+ (unsigned long long)c->resource_hiwater[i]);
}
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5b17de6..86bbc08 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -16,6 +16,7 @@
#include <linux/percpu-refcount.h>
#include <linux/percpu-rwsem.h>
#include <linux/workqueue.h>
+#include <linux/cgroupstats.h>
#ifdef CONFIG_CGROUPS
@@ -300,6 +301,10 @@ struct cgroup {
/* used to schedule release agent */
struct work_struct release_agent_work;
+#ifdef CONFIG_TASK_XACCT
+ struct cgroupstats stats;
+#endif
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
};
diff --git a/include/uapi/linux/cgroupstats.h b/include/uapi/linux/cgroupstats.h
index 3753c33..18b5b11 100644
--- a/include/uapi/linux/cgroupstats.h
+++ b/include/uapi/linux/cgroupstats.h
@@ -35,6 +35,9 @@ struct cgroupstats {
__u64 nr_uninterruptible; /* Number of tasks in uninterruptible */
/* state */
__u64 nr_io_wait; /* Number of tasks waiting on IO */
+ __u64 resource_hiwater[RLIM_NLIMITS]; /* high-watermark of
+ RLIMIT
+ resources */
};
/*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 75c0ff0..9b2d805 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -247,6 +247,7 @@ static void kill_css(struct cgroup_subsys_state *css);
static int cgroup_addrm_files(struct cgroup_subsys_state *css,
struct cgroup *cgrp, struct cftype cfts[],
bool is_add);
+static void cgroup_update_stats(void);
/**
* cgroup_ssid_enabled - cgroup subsys enabled test by subsys ID
@@ -2609,6 +2610,8 @@ out_release_tset:
list_splice_tail_init(&cset->mg_tasks, &cset->tasks);
list_del_init(&cset->mg_node);
}
+ cgroup_update_stats();
+
spin_unlock_irq(&css_set_lock);
return ret;
}
@@ -4657,6 +4660,53 @@ static int pidlist_array_load(struct cgroup *cgrp, enum cgroup_filetype type,
return 0;
}
+/*
+ * Update cgroupstats based on the stats from exiting task
+ */
+static void cgroup_update_stats_from_task(struct cgroup *cgrp,
+ struct task_struct *tsk)
+{
+ struct signal_struct *sig = tsk->signal;
+ int i;
+ unsigned int seq, nextseq;
+ unsigned long flags;
+
+ rcu_read_lock();
+ /* Attempt a lockless read on the first round. */
+ nextseq = 0;
+ do {
+ seq = nextseq;
+ flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ if (cgrp->stats.resource_hiwater[i] <
+ sig->resource_highwatermark[i])
+ cgrp->stats.resource_hiwater[i] =
+ sig->resource_highwatermark[i];
+
+ /* If lockless access failed, take the lock. */
+ nextseq = 1;
+ } while (need_seqretry(&sig->stats_lock, seq));
+ done_seqretry_irqrestore(&sig->stats_lock, seq, flags);
+ rcu_read_unlock();
+}
+
+static void cgroup_update_stats(void)
+{
+ struct cgroup_root *root;
+
+ for_each_root(root) {
+ struct cgroup *cgrp;
+
+ if (root == &cgrp_dfl_root && !cgrp_dfl_visible)
+ continue;
+
+ cgrp = task_cgroup_from_root(current, root);
+
+ if (cgroup_on_dfl(cgrp))
+ cgroup_update_stats_from_task(cgrp, current);
+ }
+}
+
/**
* cgroupstats_build - build and fill cgroupstats
* @stats: cgroupstats to fill information into
@@ -4672,6 +4722,7 @@ int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry)
struct cgroup *cgrp;
struct css_task_iter it;
struct task_struct *tsk;
+ int i;
/* it should be kernfs_node belonging to cgroupfs and is a directory */
if (dentry->d_sb->s_type != &cgroup_fs_type || !kn ||
@@ -4714,9 +4765,13 @@ int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry)
stats->nr_io_wait++;
break;
}
+ cgroup_update_stats_from_task(cgrp, tsk);
}
css_task_iter_end(&it);
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ stats->resource_hiwater[i] = cgrp->stats.resource_hiwater[i];
+
mutex_unlock(&cgroup_mutex);
return 0;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Jonathan Corbet, Tejun Heo, Li Zefan,
Johannes Weiner, Markus Elfring, David S. Miller,
Nicolas Dichtel, open list:DOCUMENTATION,
open list:CONTROL GROUP CGROUP
Collect resource usage highwater marks of a task to cgroup
statistics when the task exits.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
Documentation/accounting/getdelays.c | 10 ++++++-
include/linux/cgroup-defs.h | 5 ++++
include/uapi/linux/cgroupstats.h | 3 ++
kernel/cgroup.c | 55 ++++++++++++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index 489f1b7..7c86279 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -27,7 +27,7 @@
#include <linux/genetlink.h>
#include "include/uapi/linux/taskstats.h"
-#include <linux/cgroupstats.h>
+#include "include/uapi/linux/cgroupstats.h"
/*
* Generic macros for dealing with netlink sockets. Might be duplicated
@@ -258,12 +258,20 @@ static const char *const rlimit_names[] = {
static void print_cgroupstats(struct cgroupstats *c)
{
+ int i;
+
printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, "
"uninterruptible %llu\n", (unsigned long long)c->nr_sleeping,
(unsigned long long)c->nr_io_wait,
(unsigned long long)c->nr_running,
(unsigned long long)c->nr_stopped,
(unsigned long long)c->nr_uninterruptible);
+
+ if (print_resource_accounting)
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ printf("%s=%llu\n",
+ rlimit_names[i],
+ (unsigned long long)c->resource_hiwater[i]);
}
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5b17de6..86bbc08 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -16,6 +16,7 @@
#include <linux/percpu-refcount.h>
#include <linux/percpu-rwsem.h>
#include <linux/workqueue.h>
+#include <linux/cgroupstats.h>
#ifdef CONFIG_CGROUPS
@@ -300,6 +301,10 @@ struct cgroup {
/* used to schedule release agent */
struct work_struct release_agent_work;
+#ifdef CONFIG_TASK_XACCT
+ struct cgroupstats stats;
+#endif
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
};
diff --git a/include/uapi/linux/cgroupstats.h b/include/uapi/linux/cgroupstats.h
index 3753c33..18b5b11 100644
--- a/include/uapi/linux/cgroupstats.h
+++ b/include/uapi/linux/cgroupstats.h
@@ -35,6 +35,9 @@ struct cgroupstats {
__u64 nr_uninterruptible; /* Number of tasks in uninterruptible */
/* state */
__u64 nr_io_wait; /* Number of tasks waiting on IO */
+ __u64 resource_hiwater[RLIM_NLIMITS]; /* high-watermark of
+ RLIMIT
+ resources */
};
/*
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 75c0ff0..9b2d805 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -247,6 +247,7 @@ static void kill_css(struct cgroup_subsys_state *css);
static int cgroup_addrm_files(struct cgroup_subsys_state *css,
struct cgroup *cgrp, struct cftype cfts[],
bool is_add);
+static void cgroup_update_stats(void);
/**
* cgroup_ssid_enabled - cgroup subsys enabled test by subsys ID
@@ -2609,6 +2610,8 @@ out_release_tset:
list_splice_tail_init(&cset->mg_tasks, &cset->tasks);
list_del_init(&cset->mg_node);
}
+ cgroup_update_stats();
+
spin_unlock_irq(&css_set_lock);
return ret;
}
@@ -4657,6 +4660,53 @@ static int pidlist_array_load(struct cgroup *cgrp, enum cgroup_filetype type,
return 0;
}
+/*
+ * Update cgroupstats based on the stats from exiting task
+ */
+static void cgroup_update_stats_from_task(struct cgroup *cgrp,
+ struct task_struct *tsk)
+{
+ struct signal_struct *sig = tsk->signal;
+ int i;
+ unsigned int seq, nextseq;
+ unsigned long flags;
+
+ rcu_read_lock();
+ /* Attempt a lockless read on the first round. */
+ nextseq = 0;
+ do {
+ seq = nextseq;
+ flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ if (cgrp->stats.resource_hiwater[i] <
+ sig->resource_highwatermark[i])
+ cgrp->stats.resource_hiwater[i] =
+ sig->resource_highwatermark[i];
+
+ /* If lockless access failed, take the lock. */
+ nextseq = 1;
+ } while (need_seqretry(&sig->stats_lock, seq));
+ done_seqretry_irqrestore(&sig->stats_lock, seq, flags);
+ rcu_read_unlock();
+}
+
+static void cgroup_update_stats(void)
+{
+ struct cgroup_root *root;
+
+ for_each_root(root) {
+ struct cgroup *cgrp;
+
+ if (root == &cgrp_dfl_root && !cgrp_dfl_visible)
+ continue;
+
+ cgrp = task_cgroup_from_root(current, root);
+
+ if (cgroup_on_dfl(cgrp))
+ cgroup_update_stats_from_task(cgrp, current);
+ }
+}
+
/**
* cgroupstats_build - build and fill cgroupstats
* @stats: cgroupstats to fill information into
@@ -4672,6 +4722,7 @@ int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry)
struct cgroup *cgrp;
struct css_task_iter it;
struct task_struct *tsk;
+ int i;
/* it should be kernfs_node belonging to cgroupfs and is a directory */
if (dentry->d_sb->s_type != &cgroup_fs_type || !kn ||
@@ -4714,9 +4765,13 @@ int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry)
stats->nr_io_wait++;
break;
}
+ cgroup_update_stats_from_task(cgrp, tsk);
}
css_task_iter_end(&it);
+ for (i = 0; i < RLIM_NLIMITS; i++)
+ stats->resource_hiwater[i] = cgrp->stats.resource_hiwater[i];
+
mutex_unlock(&cgroup_mutex);
return 0;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 12:38 ` kbuild test robot
-1 siblings, 0 replies; 95+ messages in thread
From: kbuild test robot @ 2016-07-15 12:38 UTC (permalink / raw)
To: Topi Miettinen
Cc: kbuild-all, linux-kernel, Topi Miettinen, Jonathan Corbet,
Tejun Heo, Li Zefan, Johannes Weiner, Markus Elfring,
David S. Miller, Nicolas Dichtel, open list:DOCUMENTATION,
open list:CONTROL GROUP (CGROUP)
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
Hi,
[auto build test ERROR on v4.7-rc7]
[also build test ERROR on next-20160715]
[cannot apply to tip/sched/core rdma/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Topi-Miettinen/Present-useful-limits-to-user-v2/20160715-194333
config: i386-randconfig-s1-201628 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/cgroup.c: In function 'cgroup_update_stats_from_task':
>> kernel/cgroup.c:4681:12: error: 'struct cgroup' has no member named 'stats'
if (cgrp->stats.resource_hiwater[i] <
^~
>> kernel/cgroup.c:4682:11: error: 'struct signal_struct' has no member named 'resource_highwatermark'
sig->resource_highwatermark[i])
^~
kernel/cgroup.c:4683:9: error: 'struct cgroup' has no member named 'stats'
cgrp->stats.resource_hiwater[i] =
^~
kernel/cgroup.c:4684:9: error: 'struct signal_struct' has no member named 'resource_highwatermark'
sig->resource_highwatermark[i];
^~
kernel/cgroup.c: In function 'cgroupstats_build':
kernel/cgroup.c:4773:36: error: 'struct cgroup' has no member named 'stats'
stats->resource_hiwater[i] = cgrp->stats.resource_hiwater[i];
^~
vim +4681 kernel/cgroup.c
4675 /* Attempt a lockless read on the first round. */
4676 nextseq = 0;
4677 do {
4678 seq = nextseq;
4679 flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
4680 for (i = 0; i < RLIM_NLIMITS; i++)
> 4681 if (cgrp->stats.resource_hiwater[i] <
> 4682 sig->resource_highwatermark[i])
4683 cgrp->stats.resource_hiwater[i] =
4684 sig->resource_highwatermark[i];
4685
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 22648 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-15 10:35 ` Topi Miettinen
(?)
(?)
@ 2016-07-15 14:10 ` Tejun Heo
2016-07-15 17:15 ` Topi Miettinen
-1 siblings, 1 reply; 95+ messages in thread
From: Tejun Heo @ 2016-07-15 14:10 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Li Zefan, Johannes Weiner,
Markus Elfring, David S. Miller, Nicolas Dichtel,
open list:DOCUMENTATION, open list:CONTROL GROUP (CGROUP)
Hello, Topi.
On Fri, Jul 15, 2016 at 01:35:49PM +0300, Topi Miettinen wrote:
> Collect resource usage highwater marks of a task to cgroup
> statistics when the task exits.
I'm not sure how this makes sense. The limits are enforced and
collected per user or along the process hierarchy which can be very
different from cgroup organization. What does collecting high
watermarks from orthogonal structure, sometimes even combining
per-user numbers from different users, even mean? These are numbers
without clear semantics.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-15 14:10 ` Tejun Heo
@ 2016-07-15 17:15 ` Topi Miettinen
2016-07-18 22:52 ` Tejun Heo
0 siblings, 1 reply; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:15 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, Jonathan Corbet, Li Zefan, Johannes Weiner,
Markus Elfring, David S. Miller, Nicolas Dichtel,
open list:DOCUMENTATION, open list:CONTROL GROUP (CGROUP)
On 07/15/16 14:10, Tejun Heo wrote:
> Hello, Topi.
>
> On Fri, Jul 15, 2016 at 01:35:49PM +0300, Topi Miettinen wrote:
>> Collect resource usage highwater marks of a task to cgroup
>> statistics when the task exits.
>
> I'm not sure how this makes sense. The limits are enforced and
> collected per user or along the process hierarchy which can be very
> different from cgroup organization. What does collecting high
> watermarks from orthogonal structure, sometimes even combining
> per-user numbers from different users, even mean? These are numbers
> without clear semantics.
There are clear semantics for the limits themselves, either they apply
per task or per user. It makes sense to gather values according to these
semantics. Then with systemd or other tools you can use the valuse to
set the limits for a service regardless if the limit applies per task or
per user and it works according to each limit's semantics.
cgroups are used to aggregate values from a group of tasks, which still
are related to one service. Because with systemd the services also are
given a cgroup context, the values will completely make sense there too.
It could be useful to introduce a new set of limits that apply only
cgroup level. It would not remove the need to aggregate values from a
group of tasks.
-Topi
>
> Thanks.
>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-15 17:15 ` Topi Miettinen
@ 2016-07-18 22:52 ` Tejun Heo
2016-07-19 16:57 ` Topi Miettinen
0 siblings, 1 reply; 95+ messages in thread
From: Tejun Heo @ 2016-07-18 22:52 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Li Zefan, Johannes Weiner,
Markus Elfring, David S. Miller, Nicolas Dichtel,
open list:DOCUMENTATION, open list:CONTROL GROUP (CGROUP)
On Fri, Jul 15, 2016 at 05:15:41PM +0000, Topi Miettinen wrote:
> There are clear semantics for the limits themselves, either they apply
> per task or per user. It makes sense to gather values according to these
> semantics. Then with systemd or other tools you can use the valuse to
> set the limits for a service regardless if the limit applies per task or
> per user and it works according to each limit's semantics.
What does it mean to collect the maximum of the high watermarks of
multiple users or the high water marks along process hierarchy which
is spread across multiple cgroups? These are non-sensical numbers.
If you want to collect high watermarks per-cgroup, the numbers have to
be per-cgroup - how many fds are being used in that particular cgroup
and what's the high watermark of that number and so on. You can't
just take maximum from process hierarchy or user watermarks.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-18 22:52 ` Tejun Heo
@ 2016-07-19 16:57 ` Topi Miettinen
2016-07-19 18:18 ` Tejun Heo
0 siblings, 1 reply; 95+ messages in thread
From: Topi Miettinen @ 2016-07-19 16:57 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, Jonathan Corbet, Li Zefan, Johannes Weiner,
Markus Elfring, David S. Miller, Nicolas Dichtel,
open list:DOCUMENTATION, open list:CONTROL GROUP (CGROUP)
On 07/18/16 22:52, Tejun Heo wrote:
> On Fri, Jul 15, 2016 at 05:15:41PM +0000, Topi Miettinen wrote:
>> There are clear semantics for the limits themselves, either they apply
>> per task or per user. It makes sense to gather values according to these
>> semantics. Then with systemd or other tools you can use the valuse to
>> set the limits for a service regardless if the limit applies per task or
>> per user and it works according to each limit's semantics.
>
> What does it mean to collect the maximum of the high watermarks of
> multiple users or the high water marks along process hierarchy which
> is spread across multiple cgroups? These are non-sensical numbers.
> If you want to collect high watermarks per-cgroup, the numbers have to
> be per-cgroup - how many fds are being used in that particular cgroup
> and what's the high watermark of that number and so on. You can't
> just take maximum from process hierarchy or user watermarks.
Then there would need to be new limit checks at cgroup level. Would you
see problems with that approach?
-Topi
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level
2016-07-19 16:57 ` Topi Miettinen
@ 2016-07-19 18:18 ` Tejun Heo
0 siblings, 0 replies; 95+ messages in thread
From: Tejun Heo @ 2016-07-19 18:18 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Li Zefan, Johannes Weiner,
Markus Elfring, David S. Miller, Nicolas Dichtel,
open list:DOCUMENTATION, open list:CONTROL GROUP (CGROUP)
Hello, Topi.
On Tue, Jul 19, 2016 at 04:57:10PM +0000, Topi Miettinen wrote:
> Then there would need to be new limit checks at cgroup level. Would you
> see problems with that approach?
I'm worried that you're rushing this feature without thinking through
it. You were mixing up completely orthogonal planes of accounting and
control without too much thought and are now suggesting something
which is also strange. What do you mean by "new limit checks at
cgroup level"? How would this be different from the resource
accounting and control implemented in the existing controllers?
Please take a step back and think through the overall design before
proposing changes to userland visible interface.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH 03/14] resource limits: track highwater mark of file sizes
2016-07-15 10:35 ` Topi Miettinen
` (5 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Alexander Viro,
open list:FILESYSTEMS (VFS and infrastructure)
Track maximum size of files created, to be able to configure
RLIMIT_FSIZE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
fs/attr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/attr.c b/fs/attr.c
index 25b24d0..546f4f9 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -116,6 +116,8 @@ int inode_newsize_ok(const struct inode *inode, loff_t offset)
return -ETXTBSY;
}
+ update_resource_highwatermark(RLIMIT_FSIZE, offset);
+
return 0;
out_sig:
send_sig(SIGXFSZ, current, 0);
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 04/14] resource limits: track highwater mark of VM data segment
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Alexander Viro, Andrew Morton, Michal Hocko, Vlastimil Babka,
Ben Segall, Alex Thorlton, Mateusz Guzik, John Stultz,
Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
open list:FILESYSTEMS (VFS and infrastructure),
open list:MEMORY MANAGEMENT
Track maximum size of data VM, to be able to configure
RLIMIT_DATA resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/x86/ia32/ia32_aout.c | 2 ++
fs/binfmt_aout.c | 2 ++
fs/binfmt_flat.c | 2 ++
kernel/sys.c | 3 +++
mm/mmap.c | 7 ++++++-
5 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index cb26f18..9236254 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -26,6 +26,7 @@
#include <linux/init.h>
#include <linux/jiffies.h>
#include <linux/perf_event.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/pgalloc.h>
@@ -398,6 +399,7 @@ beyond_if:
regs->r8 = regs->r9 = regs->r10 = regs->r11 =
regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
set_fs(USER_DS);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index ae1b540..49216f4 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/coredump.h>
#include <linux/slab.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/cacheflush.h>
@@ -330,6 +331,7 @@ beyond_if:
regs->gp = ex.a_gpvalue;
#endif
start_thread(regs, ex.a_entry, current->mm->start_stack);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index caf9e39..19c2212 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -35,6 +35,7 @@
#include <linux/init.h>
#include <linux/flat.h>
#include <linux/syscalls.h>
+#include <linux/sched.h>
#include <asm/byteorder.h>
#include <asm/uaccess.h>
@@ -792,6 +793,7 @@ static int load_flat_file(struct linux_binprm * bprm,
libinfo->lib_list[id].start_brk) + /* start brk */
stack_len);
+ update_resource_highwatermark(RLIMIT_DATA, data_len + bss_len);
return 0;
err:
return ret;
diff --git a/kernel/sys.c b/kernel/sys.c
index 89d5be4..d84c87e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1896,6 +1896,9 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
if (prctl_map.auxv_size)
memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
+ update_resource_highwatermark(RLIMIT_DATA, mm->end_data -
+ mm->start_data);
+
up_write(&mm->mmap_sem);
return 0;
}
diff --git a/mm/mmap.c b/mm/mmap.c
index de2c176..0b10f56 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -228,6 +228,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
goto out;
set_brk:
+ update_resource_highwatermark(RLIMIT_DATA, (brk - mm->start_brk) +
+ (mm->end_data - mm->start_data));
mm->brk = brk;
populate = newbrk > oldbrk && (mm->def_flags & VM_LOCKED) != 0;
up_write(&mm->mmap_sem);
@@ -2924,8 +2926,11 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
mm->exec_vm += npages;
else if (is_stack_mapping(flags))
mm->stack_vm += npages;
- else if (is_data_mapping(flags))
+ else if (is_data_mapping(flags)) {
mm->data_vm += npages;
+ update_resource_highwatermark(RLIMIT_DATA,
+ mm->data_vm << PAGE_SHIFT);
+ }
}
static int special_mapping_fault(struct vm_area_struct *vma,
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 04/14] resource limits: track highwater mark of VM data segment
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Alexander Viro,
Andrew Morton, Michal Hocko, Vlastimil Babka, Ben Segall,
Alex Thorlton, Mateusz Guzik, John Stultz, Kirill A. Shutemov,
Oleg Nesterov, Chen Gang, Konstantin Khlebnikov,
Andrea Arcangeli, Andrey Ryabinin,
open list:FILESYSTEMS VFS and infrastructure,
open list:MEMORY MANAGEMENT
Track maximum size of data VM, to be able to configure
RLIMIT_DATA resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/x86/ia32/ia32_aout.c | 2 ++
fs/binfmt_aout.c | 2 ++
fs/binfmt_flat.c | 2 ++
kernel/sys.c | 3 +++
mm/mmap.c | 7 ++++++-
5 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index cb26f18..9236254 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -26,6 +26,7 @@
#include <linux/init.h>
#include <linux/jiffies.h>
#include <linux/perf_event.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/pgalloc.h>
@@ -398,6 +399,7 @@ beyond_if:
regs->r8 = regs->r9 = regs->r10 = regs->r11 =
regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
set_fs(USER_DS);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index ae1b540..49216f4 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/coredump.h>
#include <linux/slab.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/cacheflush.h>
@@ -330,6 +331,7 @@ beyond_if:
regs->gp = ex.a_gpvalue;
#endif
start_thread(regs, ex.a_entry, current->mm->start_stack);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index caf9e39..19c2212 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -35,6 +35,7 @@
#include <linux/init.h>
#include <linux/flat.h>
#include <linux/syscalls.h>
+#include <linux/sched.h>
#include <asm/byteorder.h>
#include <asm/uaccess.h>
@@ -792,6 +793,7 @@ static int load_flat_file(struct linux_binprm * bprm,
libinfo->lib_list[id].start_brk) + /* start brk */
stack_len);
+ update_resource_highwatermark(RLIMIT_DATA, data_len + bss_len);
return 0;
err:
return ret;
diff --git a/kernel/sys.c b/kernel/sys.c
index 89d5be4..d84c87e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1896,6 +1896,9 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
if (prctl_map.auxv_size)
memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
+ update_resource_highwatermark(RLIMIT_DATA, mm->end_data -
+ mm->start_data);
+
up_write(&mm->mmap_sem);
return 0;
}
diff --git a/mm/mmap.c b/mm/mmap.c
index de2c176..0b10f56 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -228,6 +228,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
goto out;
set_brk:
+ update_resource_highwatermark(RLIMIT_DATA, (brk - mm->start_brk) +
+ (mm->end_data - mm->start_data));
mm->brk = brk;
populate = newbrk > oldbrk && (mm->def_flags & VM_LOCKED) != 0;
up_write(&mm->mmap_sem);
@@ -2924,8 +2926,11 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
mm->exec_vm += npages;
else if (is_stack_mapping(flags))
mm->stack_vm += npages;
- else if (is_data_mapping(flags))
+ else if (is_data_mapping(flags)) {
mm->data_vm += npages;
+ update_resource_highwatermark(RLIMIT_DATA,
+ mm->data_vm << PAGE_SHIFT);
+ }
}
static int special_mapping_fault(struct vm_area_struct *vma,
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 04/14] resource limits: track highwater mark of VM data segment
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Alexander Viro, Andrew Morton, Michal Hocko, Vlastimil Babka,
Ben Segall, Alex Thorlton, Mateusz Guzik, John Stultz,
Kirill A. Shutemov, Oleg Nesterov, Chen Gang,
Konstantin Khlebnikov, Andrea Arcangeli, Andrey Ryabinin,
open list:FILESYSTEMS (VFS and infrastructure),
open list:MEMORY MANAGEMENT
Track maximum size of data VM, to be able to configure
RLIMIT_DATA resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/x86/ia32/ia32_aout.c | 2 ++
fs/binfmt_aout.c | 2 ++
fs/binfmt_flat.c | 2 ++
kernel/sys.c | 3 +++
mm/mmap.c | 7 ++++++-
5 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index cb26f18..9236254 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -26,6 +26,7 @@
#include <linux/init.h>
#include <linux/jiffies.h>
#include <linux/perf_event.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/pgalloc.h>
@@ -398,6 +399,7 @@ beyond_if:
regs->r8 = regs->r9 = regs->r10 = regs->r11 =
regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
set_fs(USER_DS);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index ae1b540..49216f4 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/coredump.h>
#include <linux/slab.h>
+#include <linux/sched.h>
#include <asm/uaccess.h>
#include <asm/cacheflush.h>
@@ -330,6 +331,7 @@ beyond_if:
regs->gp = ex.a_gpvalue;
#endif
start_thread(regs, ex.a_entry, current->mm->start_stack);
+ update_resource_highwatermark(RLIMIT_DATA, ex.a_data + ex.a_bss);
return 0;
}
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index caf9e39..19c2212 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -35,6 +35,7 @@
#include <linux/init.h>
#include <linux/flat.h>
#include <linux/syscalls.h>
+#include <linux/sched.h>
#include <asm/byteorder.h>
#include <asm/uaccess.h>
@@ -792,6 +793,7 @@ static int load_flat_file(struct linux_binprm * bprm,
libinfo->lib_list[id].start_brk) + /* start brk */
stack_len);
+ update_resource_highwatermark(RLIMIT_DATA, data_len + bss_len);
return 0;
err:
return ret;
diff --git a/kernel/sys.c b/kernel/sys.c
index 89d5be4..d84c87e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1896,6 +1896,9 @@ static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data
if (prctl_map.auxv_size)
memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
+ update_resource_highwatermark(RLIMIT_DATA, mm->end_data -
+ mm->start_data);
+
up_write(&mm->mmap_sem);
return 0;
}
diff --git a/mm/mmap.c b/mm/mmap.c
index de2c176..0b10f56 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -228,6 +228,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
goto out;
set_brk:
+ update_resource_highwatermark(RLIMIT_DATA, (brk - mm->start_brk) +
+ (mm->end_data - mm->start_data));
mm->brk = brk;
populate = newbrk > oldbrk && (mm->def_flags & VM_LOCKED) != 0;
up_write(&mm->mmap_sem);
@@ -2924,8 +2926,11 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
mm->exec_vm += npages;
else if (is_stack_mapping(flags))
mm->stack_vm += npages;
- else if (is_data_mapping(flags))
+ else if (is_data_mapping(flags)) {
mm->data_vm += npages;
+ update_resource_highwatermark(RLIMIT_DATA,
+ mm->data_vm << PAGE_SHIFT);
+ }
}
static int special_mapping_fault(struct vm_area_struct *vma,
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 05/14] resource limits: track highwater mark of stack size
2016-07-15 10:35 ` Topi Miettinen
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Andrew Morton, Oleg Nesterov, Kirill A. Shutemov,
Chen Gang, Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
Andrey Ryabinin, open list:MEMORY MANAGEMENT
Track maximum stack size, to be able to configure
RLIMIT_STACK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
mm/mmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 0b10f56..305c456 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2019,6 +2019,8 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
if (security_vm_enough_memory_mm(mm, grow))
return -ENOMEM;
+ update_resource_highwatermark(RLIMIT_STACK, actual_size);
+
return 0;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 05/14] resource limits: track highwater mark of stack size
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Andrew Morton, Oleg Nesterov, Kirill A. Shutemov,
Chen Gang, Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
Andrey Ryabinin, open list:MEMORY MANAGEMENT
Track maximum stack size, to be able to configure
RLIMIT_STACK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
mm/mmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 0b10f56..305c456 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2019,6 +2019,8 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
if (security_vm_enough_memory_mm(mm, grow))
return -ENOMEM;
+ update_resource_highwatermark(RLIMIT_STACK, actual_size);
+
return 0;
}
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 06/14] resource limits: track highwater mark of cores dumped
2016-07-15 10:35 ` Topi Miettinen
` (8 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Alexander Viro,
open list:FILESYSTEMS (VFS and infrastructure)
Track maximum size of core dump written, to be able to configure
RLIMIT_CORE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
fs/coredump.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 281b768..a0ace88 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -784,20 +784,25 @@ int dump_emit(struct coredump_params *cprm, const void *addr, int nr)
struct file *file = cprm->file;
loff_t pos = file->f_pos;
ssize_t n;
+ int r = 0;
+
if (cprm->written + nr > cprm->limit)
return 0;
while (nr) {
if (dump_interrupted())
- return 0;
+ goto err;
n = __kernel_write(file, addr, nr, &pos);
if (n <= 0)
- return 0;
+ goto err;
file->f_pos = pos;
cprm->written += n;
cprm->pos += n;
nr -= n;
}
- return 1;
+ r = 1;
+ err:
+ update_resource_highwatermark(RLIMIT_CORE, cprm->written);
+ return r;
}
EXPORT_SYMBOL(dump_emit);
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 07/14] resource limits: track highwater mark of user processes
2016-07-15 10:35 ` Topi Miettinen
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Ingo Molnar, Peter Zijlstra, Tejun Heo, Li Zefan,
Johannes Weiner, Andrew Morton, Michal Hocko, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Cyrill Gorcunov,
Mateusz Guzik, John Stultz, Ben Segall, Rik van Riel,
Thomas Gleixner, open list:CONTROL GROUP (CGROUP)
Track maximum number of processes per user, to be able to configure
RLIMIT_NPROC resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
include/linux/sched.h | 30 ++++++++++++++++++++++++++++++
kernel/cgroup.c | 31 +++++++++++++++++++++++++++----
kernel/cred.c | 1 +
kernel/fork.c | 2 ++
kernel/sys.c | 2 ++
kernel/tsacct.c | 23 ++++++++++++++++++++++-
6 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e4d7482..d6af49b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -840,6 +840,7 @@ static inline int signal_group_exit(const struct signal_struct *sig)
struct user_struct {
atomic_t __count; /* reference count */
atomic_t processes; /* How many processes does this user have? */
+ atomic_t max_processes; /* How many processes has this user had at the same time? */
atomic_t sigpending; /* How many pending signals does this user have? */
#ifdef CONFIG_INOTIFY_USER
atomic_t inotify_watches; /* How many inotify watches does this user have? */
@@ -3344,6 +3345,27 @@ static inline void update_resource_highwatermark(unsigned int limit,
{
task_update_resource_highwatermark(current, limit, r);
}
+
+static inline void user_update_maxproc_highwatermark(struct user_struct *u)
+{
+ int processes;
+
+ processes = atomic_read(&u->processes);
+ if (atomic_read(&u->max_processes) < processes)
+ atomic_set(&u->max_processes, processes);
+}
+
+static inline void task_update_maxproc_highwatermark(struct task_struct *t)
+{
+ const struct cred *tcred;
+
+ rcu_read_lock();
+ tcred = __task_cred(t);
+
+ user_update_maxproc_highwatermark(tcred->user);
+
+ rcu_read_unlock();
+}
#else
static inline void add_rchar(struct task_struct *tsk, ssize_t amt)
{
@@ -3370,6 +3392,14 @@ static inline void update_resource_highwatermark(unsigned int limit,
unsigned long r)
{
}
+
+static inline void user_update_maxproc_highwatermark(struct user_struct *u)
+{
+}
+
+static inline void task_update_maxproc_highwatermark(struct task_struct *t)
+{
+}
#endif
#ifndef TASK_SIZE_OF
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 9b2d805..38a272f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4660,6 +4660,23 @@ static int pidlist_array_load(struct cgroup *cgrp, enum cgroup_filetype type,
return 0;
}
+static void cgroup_update_maxproc_highwatermark(struct cgroup *cgrp,
+ struct task_struct *t)
+{
+ const struct cred *tcred;
+ struct user_struct *u;
+ int max_processes;
+
+ tcred = __task_cred(t);
+ u = tcred->user;
+
+ user_update_maxproc_highwatermark(u);
+
+ max_processes = atomic_read(&u->max_processes);
+ if (cgrp->stats.resource_hiwater[RLIMIT_NPROC] < max_processes)
+ cgrp->stats.resource_hiwater[RLIMIT_NPROC] = max_processes;
+}
+
/*
* Update cgroupstats based on the stats from exiting task
*/
@@ -4678,10 +4695,16 @@ static void cgroup_update_stats_from_task(struct cgroup *cgrp,
seq = nextseq;
flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
for (i = 0; i < RLIM_NLIMITS; i++)
- if (cgrp->stats.resource_hiwater[i] <
- sig->resource_highwatermark[i])
- cgrp->stats.resource_hiwater[i] =
- sig->resource_highwatermark[i];
+ switch(i) {
+ case RLIMIT_NPROC:
+ cgroup_update_maxproc_highwatermark(cgrp, tsk);
+ break;
+ default:
+ if (cgrp->stats.resource_hiwater[i] <
+ sig->resource_highwatermark[i])
+ cgrp->stats.resource_hiwater[i] =
+ sig->resource_highwatermark[i];
+ }
/* If lockless access failed, take the lock. */
nextseq = 1;
diff --git a/kernel/cred.c b/kernel/cred.c
index 0c0cd8a..e12ab6e 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -467,6 +467,7 @@ int commit_creds(struct cred *new)
rcu_assign_pointer(task->cred, new);
if (new->user != old->user)
atomic_dec(&old->user->processes);
+ user_update_maxproc_highwatermark(new->user);
alter_cred_subscribers(old, -2);
/* send notifications */
diff --git a/kernel/fork.c b/kernel/fork.c
index 4a7ec0c..3f636c7 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1640,6 +1640,8 @@ static struct task_struct *copy_process(unsigned long clone_flags,
nr_threads++;
}
+ task_update_maxproc_highwatermark(p);
+
total_forks++;
spin_unlock(¤t->sighand->siglock);
syscall_tracepoint_update(p);
diff --git a/kernel/sys.c b/kernel/sys.c
index d84c87e..f1def17 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -439,6 +439,8 @@ static int set_user(struct cred *new)
else
current->flags &= ~PF_NPROC_EXCEEDED;
+ user_update_maxproc_highwatermark(new_user);
+
free_uid(new->user);
new->user = new_user;
return 0;
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 231bae3..9fd4cef 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -184,6 +184,19 @@ void acct_clear_integrals(struct task_struct *tsk)
tsk->acct_vm_mem1 = 0;
}
+static __u64 task_get_maxproc_highwatermark(struct task_struct *t)
+{
+ const struct cred *tcred;
+ struct user_struct *u;
+
+ tcred = __task_cred(t);
+ u = tcred->user;
+
+ user_update_maxproc_highwatermark(u);
+
+ return (__u64)atomic_read(&u->max_processes);
+}
+
/*
* fill in resource accounting fields
*/
@@ -201,7 +214,15 @@ void racct_add_tsk(struct taskstats *stats, struct task_struct *tsk)
seq = nextseq;
flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
for (i = 0; i < RLIM_NLIMITS; i++)
- stats->resource_hiwater[i] = (__u64)sig->resource_highwatermark[i];
+ switch(i) {
+ case RLIMIT_NPROC:
+ stats->resource_hiwater[i] =
+ task_get_maxproc_highwatermark(tsk);
+ break;
+ default:
+ stats->resource_hiwater[i] =
+ (__u64)sig->resource_highwatermark[i];
+ }
/* If lockless access failed, take the lock. */
nextseq = 1;
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 07/14] resource limits: track highwater mark of user processes
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Ingo Molnar, Peter Zijlstra, Tejun Heo, Li Zefan,
Johannes Weiner, Andrew Morton, Michal Hocko, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Cyrill Gorcunov,
Mateusz Guzik, John Stultz, Ben Segall, Rik van Riel,
Thomas Gleixner, open list:CONTROL GROUP CGROUP
Track maximum number of processes per user, to be able to configure
RLIMIT_NPROC resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
include/linux/sched.h | 30 ++++++++++++++++++++++++++++++
kernel/cgroup.c | 31 +++++++++++++++++++++++++++----
kernel/cred.c | 1 +
kernel/fork.c | 2 ++
kernel/sys.c | 2 ++
kernel/tsacct.c | 23 ++++++++++++++++++++++-
6 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e4d7482..d6af49b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -840,6 +840,7 @@ static inline int signal_group_exit(const struct signal_struct *sig)
struct user_struct {
atomic_t __count; /* reference count */
atomic_t processes; /* How many processes does this user have? */
+ atomic_t max_processes; /* How many processes has this user had at the same time? */
atomic_t sigpending; /* How many pending signals does this user have? */
#ifdef CONFIG_INOTIFY_USER
atomic_t inotify_watches; /* How many inotify watches does this user have? */
@@ -3344,6 +3345,27 @@ static inline void update_resource_highwatermark(unsigned int limit,
{
task_update_resource_highwatermark(current, limit, r);
}
+
+static inline void user_update_maxproc_highwatermark(struct user_struct *u)
+{
+ int processes;
+
+ processes = atomic_read(&u->processes);
+ if (atomic_read(&u->max_processes) < processes)
+ atomic_set(&u->max_processes, processes);
+}
+
+static inline void task_update_maxproc_highwatermark(struct task_struct *t)
+{
+ const struct cred *tcred;
+
+ rcu_read_lock();
+ tcred = __task_cred(t);
+
+ user_update_maxproc_highwatermark(tcred->user);
+
+ rcu_read_unlock();
+}
#else
static inline void add_rchar(struct task_struct *tsk, ssize_t amt)
{
@@ -3370,6 +3392,14 @@ static inline void update_resource_highwatermark(unsigned int limit,
unsigned long r)
{
}
+
+static inline void user_update_maxproc_highwatermark(struct user_struct *u)
+{
+}
+
+static inline void task_update_maxproc_highwatermark(struct task_struct *t)
+{
+}
#endif
#ifndef TASK_SIZE_OF
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 9b2d805..38a272f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4660,6 +4660,23 @@ static int pidlist_array_load(struct cgroup *cgrp, enum cgroup_filetype type,
return 0;
}
+static void cgroup_update_maxproc_highwatermark(struct cgroup *cgrp,
+ struct task_struct *t)
+{
+ const struct cred *tcred;
+ struct user_struct *u;
+ int max_processes;
+
+ tcred = __task_cred(t);
+ u = tcred->user;
+
+ user_update_maxproc_highwatermark(u);
+
+ max_processes = atomic_read(&u->max_processes);
+ if (cgrp->stats.resource_hiwater[RLIMIT_NPROC] < max_processes)
+ cgrp->stats.resource_hiwater[RLIMIT_NPROC] = max_processes;
+}
+
/*
* Update cgroupstats based on the stats from exiting task
*/
@@ -4678,10 +4695,16 @@ static void cgroup_update_stats_from_task(struct cgroup *cgrp,
seq = nextseq;
flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
for (i = 0; i < RLIM_NLIMITS; i++)
- if (cgrp->stats.resource_hiwater[i] <
- sig->resource_highwatermark[i])
- cgrp->stats.resource_hiwater[i] =
- sig->resource_highwatermark[i];
+ switch(i) {
+ case RLIMIT_NPROC:
+ cgroup_update_maxproc_highwatermark(cgrp, tsk);
+ break;
+ default:
+ if (cgrp->stats.resource_hiwater[i] <
+ sig->resource_highwatermark[i])
+ cgrp->stats.resource_hiwater[i] =
+ sig->resource_highwatermark[i];
+ }
/* If lockless access failed, take the lock. */
nextseq = 1;
diff --git a/kernel/cred.c b/kernel/cred.c
index 0c0cd8a..e12ab6e 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -467,6 +467,7 @@ int commit_creds(struct cred *new)
rcu_assign_pointer(task->cred, new);
if (new->user != old->user)
atomic_dec(&old->user->processes);
+ user_update_maxproc_highwatermark(new->user);
alter_cred_subscribers(old, -2);
/* send notifications */
diff --git a/kernel/fork.c b/kernel/fork.c
index 4a7ec0c..3f636c7 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1640,6 +1640,8 @@ static struct task_struct *copy_process(unsigned long clone_flags,
nr_threads++;
}
+ task_update_maxproc_highwatermark(p);
+
total_forks++;
spin_unlock(¤t->sighand->siglock);
syscall_tracepoint_update(p);
diff --git a/kernel/sys.c b/kernel/sys.c
index d84c87e..f1def17 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -439,6 +439,8 @@ static int set_user(struct cred *new)
else
current->flags &= ~PF_NPROC_EXCEEDED;
+ user_update_maxproc_highwatermark(new_user);
+
free_uid(new->user);
new->user = new_user;
return 0;
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 231bae3..9fd4cef 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -184,6 +184,19 @@ void acct_clear_integrals(struct task_struct *tsk)
tsk->acct_vm_mem1 = 0;
}
+static __u64 task_get_maxproc_highwatermark(struct task_struct *t)
+{
+ const struct cred *tcred;
+ struct user_struct *u;
+
+ tcred = __task_cred(t);
+ u = tcred->user;
+
+ user_update_maxproc_highwatermark(u);
+
+ return (__u64)atomic_read(&u->max_processes);
+}
+
/*
* fill in resource accounting fields
*/
@@ -201,7 +214,15 @@ void racct_add_tsk(struct taskstats *stats, struct task_struct *tsk)
seq = nextseq;
flags = read_seqbegin_or_lock_irqsave(&sig->stats_lock, &seq);
for (i = 0; i < RLIM_NLIMITS; i++)
- stats->resource_hiwater[i] = (__u64)sig->resource_highwatermark[i];
+ switch(i) {
+ case RLIMIT_NPROC:
+ stats->resource_hiwater[i] =
+ task_get_maxproc_highwatermark(tsk);
+ break;
+ default:
+ stats->resource_hiwater[i] =
+ (__u64)sig->resource_highwatermark[i];
+ }
/* If lockless access failed, take the lock. */
nextseq = 1;
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 08/14] resource limits: track highwater mark of number of files
2016-07-15 10:35 ` Topi Miettinen
` (10 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Alexander Viro,
open list:FILESYSTEMS (VFS and infrastructure)
Track maximum number of files for the process, to be able to configure
RLIMIT_NOFILE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
fs/file.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/file.c b/fs/file.c
index 6b1acdf..9de37c9 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -547,6 +547,8 @@ repeat:
}
#endif
+ update_resource_highwatermark(RLIMIT_NOFILE, fd);
+
out:
spin_unlock(&files->file_lock);
return error;
@@ -857,6 +859,8 @@ __releases(&files->file_lock)
if (tofree)
filp_close(tofree, files);
+ update_resource_highwatermark(RLIMIT_NOFILE, fd);
+
return fd;
Ebusy:
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 09/14] resource limits: track highwater mark of locked memory
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar
Track maximum size of locked memory, to be able to configure
RLIMIT_MEMLOCK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 ++
arch/powerpc/mm/mmu_context_iommu.c | 2 ++
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 ++
drivers/infiniband/hw/qib/qib_user_pages.c | 2 ++
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 +++++
kernel/bpf/syscall.c | 8 ++++++++
kernel/events/core.c | 1 +
mm/mlock.c | 8 ++++++++
mm/mmap.c | 4 ++++
mm/mremap.c | 4 ++++
15 files changed, 45 insertions(+)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 2436ad5..7c6ae72 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2341,6 +2341,7 @@ pfm_smpl_buffer_alloc(struct task_struct *task, struct file *filp, pfm_context_t
ctx->ctx_smpl_vaddr = (void *)vma->vm_start;
*(unsigned long *)user_vaddr = vma->vm_start;
+ task_update_resource_highwatermark(task, RLIMIT_MEMLOCK, size);
return 0;
error:
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1..40ea177 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -71,6 +71,8 @@ static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
ret = -ENOMEM;
else
current->mm->locked_vm += stt_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
stt_pages = current->mm->locked_vm;
diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
index da6a216..8c6bcbf 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -46,6 +46,8 @@ static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
ret = -ENOMEM;
else
mm->locked_vm += npages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(npages > mm->locked_vm))
npages = mm->locked_vm;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1..3c454eb 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -224,6 +224,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
ret = 0;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
out:
if (ret < 0) {
if (need_release)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c b/drivers/infiniband/hw/hfi1/user_pages.c
index 88e10b5f..ca55f8c 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -111,6 +111,8 @@ int hfi1_acquire_user_pages(unsigned long vaddr, size_t npages, bool writable,
down_write(¤t->mm->mmap_sem);
current->mm->pinned_vm += ret;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
index 2d2b94f..3a103c4 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -74,6 +74,8 @@ static int __qib_get_user_pages(unsigned long start_page, size_t num_pages,
}
current->mm->pinned_vm += num_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
ret = 0;
goto bail;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c
index a0b6ebe..6180654 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -178,6 +178,8 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
ret = 0;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
out:
if (ret < 0)
usnic_uiom_put_pages(chunk_list, 0);
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index e0203b1..acb970a 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -306,6 +306,7 @@ static inline int __scif_check_inc_pinned_vm(struct mm_struct *mm,
return -ENOMEM;
}
mm->pinned_vm = locked;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
return 0;
}
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index 80378dd..13ee9e9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -55,6 +55,8 @@ static long try_increment_locked_vm(long npages)
rlimit(RLIMIT_MEMLOCK),
ret ? " - exceeded" : "");
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2ba1942..e868ae5 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -145,6 +145,8 @@ static void vfio_lock_acct_bg(struct work_struct *work)
mm = vwork->mm;
down_write(&mm->mmap_sem);
mm->locked_vm += vwork->npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm << PAGE_SHIFT);
up_write(&mm->mmap_sem);
mmput(mm);
kfree(vwork);
@@ -160,6 +162,9 @@ static void vfio_lock_acct(long npage)
if (down_write_trylock(¤t->mm->mmap_sem)) {
current->mm->locked_vm += npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm <<
+ PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return;
}
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 46ecce4..0efa1c3 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -76,6 +76,10 @@ static int bpf_map_charge_memlock(struct bpf_map *map)
return -EPERM;
}
map->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
@@ -601,6 +605,10 @@ static int bpf_prog_charge_memlock(struct bpf_prog *prog)
return -EPERM;
}
prog->aux->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 43d43a2d..4b8b143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5096,6 +5096,7 @@ accounting:
if (!ret)
rb->aux_mmap_locked = extra;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
unlock:
if (!ret) {
diff --git a/mm/mlock.c b/mm/mlock.c
index ef8dc9f..eb45857 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -648,6 +648,8 @@ static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t fla
if (error)
return error;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
error = __mm_populate(start, len, 0);
if (error)
return __mlock_posix_error_return(error);
@@ -761,6 +763,9 @@ SYSCALL_DEFINE1(mlockall, int, flags)
if (!ret && (flags & MCL_CURRENT))
mm_populate(0, TASK_SIZE);
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->total_vm << PAGE_SHIFT);
+
return ret;
}
@@ -798,6 +803,9 @@ int user_shm_lock(size_t size, struct user_struct *user)
get_uid(user);
user->locked_shm += locked;
allowed = 1;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ user->locked_shm << PAGE_SHIFT);
out:
spin_unlock(&shmlock_user_lock);
return allowed;
diff --git a/mm/mmap.c b/mm/mmap.c
index 305c456..c37f599 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
return -ENOMEM;
update_resource_highwatermark(RLIMIT_STACK, actual_size);
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm + grow) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/mm/mremap.c b/mm/mremap.c
index 1f157ad..f1821335 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -394,6 +394,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
*p = charged;
}
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm << PAGE_SHIFT) +
+ new_len - old_len);
return vma;
}
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Oleg Nesterov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
Track maximum size of locked memory, to be able to configure
RLIMIT_MEMLOCK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 ++
arch/powerpc/mm/mmu_context_iommu.c | 2 ++
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 ++
drivers/infiniband/hw/qib/qib_user_pages.c | 2 ++
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 +++++
kernel/bpf/syscall.c | 8 ++++++++
kernel/events/core.c | 1 +
mm/mlock.c | 8 ++++++++
mm/mmap.c | 4 ++++
mm/mremap.c | 4 ++++
15 files changed, 45 insertions(+)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 2436ad5..7c6ae72 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2341,6 +2341,7 @@ pfm_smpl_buffer_alloc(struct task_struct *task, struct file *filp, pfm_context_t
ctx->ctx_smpl_vaddr = (void *)vma->vm_start;
*(unsigned long *)user_vaddr = vma->vm_start;
+ task_update_resource_highwatermark(task, RLIMIT_MEMLOCK, size);
return 0;
error:
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1..40ea177 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -71,6 +71,8 @@ static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
ret = -ENOMEM;
else
current->mm->locked_vm += stt_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
stt_pages = current->mm->locked_vm;
diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
index da6a216..8c6bcbf 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -46,6 +46,8 @@ static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
ret = -ENOMEM;
else
mm->locked_vm += npages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(npages > mm->locked_vm))
npages = mm->locked_vm;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1..3c454eb 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -224,6 +224,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
ret = 0;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
out:
if (ret < 0) {
if (need_release)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c b/drivers/infiniband/hw/hfi1/user_pages.c
index 88e10b5f..ca55f8c 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -111,6 +111,8 @@ int hfi1_acquire_user_pages(unsigned long vaddr, size_t npages, bool writable,
down_write(¤t->mm->mmap_sem);
current->mm->pinned_vm += ret;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
index 2d2b94f..3a103c4 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -74,6 +74,8 @@ static int __qib_get_user_pages(unsigned long start_page, size_t num_pages,
}
current->mm->pinned_vm += num_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
ret = 0;
goto bail;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c
index a0b6ebe..6180654 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -178,6 +178,8 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
ret = 0;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
out:
if (ret < 0)
usnic_uiom_put_pages(chunk_list, 0);
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index e0203b1..acb970a 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -306,6 +306,7 @@ static inline int __scif_check_inc_pinned_vm(struct mm_struct *mm,
return -ENOMEM;
}
mm->pinned_vm = locked;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
return 0;
}
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index 80378dd..13ee9e9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -55,6 +55,8 @@ static long try_increment_locked_vm(long npages)
rlimit(RLIMIT_MEMLOCK),
ret ? " - exceeded" : "");
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2ba1942..e868ae5 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -145,6 +145,8 @@ static void vfio_lock_acct_bg(struct work_struct *work)
mm = vwork->mm;
down_write(&mm->mmap_sem);
mm->locked_vm += vwork->npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm << PAGE_SHIFT);
up_write(&mm->mmap_sem);
mmput(mm);
kfree(vwork);
@@ -160,6 +162,9 @@ static void vfio_lock_acct(long npage)
if (down_write_trylock(¤t->mm->mmap_sem)) {
current->mm->locked_vm += npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm <<
+ PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return;
}
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 46ecce4..0efa1c3 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -76,6 +76,10 @@ static int bpf_map_charge_memlock(struct bpf_map *map)
return -EPERM;
}
map->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
@@ -601,6 +605,10 @@ static int bpf_prog_charge_memlock(struct bpf_prog *prog)
return -EPERM;
}
prog->aux->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 43d43a2d..4b8b143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5096,6 +5096,7 @@ accounting:
if (!ret)
rb->aux_mmap_locked = extra;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
unlock:
if (!ret) {
diff --git a/mm/mlock.c b/mm/mlock.c
index ef8dc9f..eb45857 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -648,6 +648,8 @@ static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t fla
if (error)
return error;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
error = __mm_populate(start, len, 0);
if (error)
return __mlock_posix_error_return(error);
@@ -761,6 +763,9 @@ SYSCALL_DEFINE1(mlockall, int, flags)
if (!ret && (flags & MCL_CURRENT))
mm_populate(0, TASK_SIZE);
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->total_vm << PAGE_SHIFT);
+
return ret;
}
@@ -798,6 +803,9 @@ int user_shm_lock(size_t size, struct user_struct *user)
get_uid(user);
user->locked_shm += locked;
allowed = 1;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ user->locked_shm << PAGE_SHIFT);
out:
spin_unlock(&shmlock_user_lock);
return allowed;
diff --git a/mm/mmap.c b/mm/mmap.c
index 305c456..c37f599 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
return -ENOMEM;
update_resource_highwatermark(RLIMIT_STACK, actual_size);
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm + grow) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/mm/mremap.c b/mm/mremap.c
index 1f157ad..f1821335 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -394,6 +394,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
*p = charged;
}
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm << PAGE_SHIFT) +
+ new_len - old_len);
return vma;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Oleg Nesterov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:IA64 Itanium PLATFORM,
open list:KERNEL VIRTUAL MACHINE KVM,
open list:KERNEL VIRTUAL MACHINE KVM FOR POWERPC,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT,
open list:INFINIBAND SUBSYSTEM,
open list:BPF Safe dynamic programs and tools,
open list:MEMORY MANAGEMENT
Track maximum size of locked memory, to be able to configure
RLIMIT_MEMLOCK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 ++
arch/powerpc/mm/mmu_context_iommu.c | 2 ++
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 ++
drivers/infiniband/hw/qib/qib_user_pages.c | 2 ++
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 +++++
kernel/bpf/syscall.c | 8 ++++++++
kernel/events/core.c | 1 +
mm/mlock.c | 8 ++++++++
mm/mmap.c | 4 ++++
mm/mremap.c | 4 ++++
15 files changed, 45 insertions(+)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 2436ad5..7c6ae72 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2341,6 +2341,7 @@ pfm_smpl_buffer_alloc(struct task_struct *task, struct file *filp, pfm_context_t
ctx->ctx_smpl_vaddr = (void *)vma->vm_start;
*(unsigned long *)user_vaddr = vma->vm_start;
+ task_update_resource_highwatermark(task, RLIMIT_MEMLOCK, size);
return 0;
error:
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1..40ea177 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -71,6 +71,8 @@ static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
ret = -ENOMEM;
else
current->mm->locked_vm += stt_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
stt_pages = current->mm->locked_vm;
diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
index da6a216..8c6bcbf 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -46,6 +46,8 @@ static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
ret = -ENOMEM;
else
mm->locked_vm += npages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(npages > mm->locked_vm))
npages = mm->locked_vm;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1..3c454eb 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -224,6 +224,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
ret = 0;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
out:
if (ret < 0) {
if (need_release)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c b/drivers/infiniband/hw/hfi1/user_pages.c
index 88e10b5f..ca55f8c 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -111,6 +111,8 @@ int hfi1_acquire_user_pages(unsigned long vaddr, size_t npages, bool writable,
down_write(¤t->mm->mmap_sem);
current->mm->pinned_vm += ret;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
index 2d2b94f..3a103c4 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -74,6 +74,8 @@ static int __qib_get_user_pages(unsigned long start_page, size_t num_pages,
}
current->mm->pinned_vm += num_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
ret = 0;
goto bail;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c
index a0b6ebe..6180654 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -178,6 +178,8 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
ret = 0;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
out:
if (ret < 0)
usnic_uiom_put_pages(chunk_list, 0);
diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
index e0203b1..acb970a 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -306,6 +306,7 @@ static inline int __scif_check_inc_pinned_vm(struct mm_struct *mm,
return -ENOMEM;
}
mm->pinned_vm = locked;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
return 0;
}
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index 80378dd..13ee9e9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -55,6 +55,8 @@ static long try_increment_locked_vm(long npages)
rlimit(RLIMIT_MEMLOCK),
ret ? " - exceeded" : "");
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2ba1942..e868ae5 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -145,6 +145,8 @@ static void vfio_lock_acct_bg(struct work_struct *work)
mm = vwork->mm;
down_write(&mm->mmap_sem);
mm->locked_vm += vwork->npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm << PAGE_SHIFT);
up_write(&mm->mmap_sem);
mmput(mm);
kfree(vwork);
@@ -160,6 +162,9 @@ static void vfio_lock_acct(long npage)
if (down_write_trylock(¤t->mm->mmap_sem)) {
current->mm->locked_vm += npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm <<
+ PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return;
}
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 46ecce4..0efa1c3 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -76,6 +76,10 @@ static int bpf_map_charge_memlock(struct bpf_map *map)
return -EPERM;
}
map->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
@@ -601,6 +605,10 @@ static int bpf_prog_charge_memlock(struct bpf_prog *prog)
return -EPERM;
}
prog->aux->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 43d43a2d..4b8b143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5096,6 +5096,7 @@ accounting:
if (!ret)
rb->aux_mmap_locked = extra;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
unlock:
if (!ret) {
diff --git a/mm/mlock.c b/mm/mlock.c
index ef8dc9f..eb45857 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -648,6 +648,8 @@ static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t fla
if (error)
return error;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
error = __mm_populate(start, len, 0);
if (error)
return __mlock_posix_error_return(error);
@@ -761,6 +763,9 @@ SYSCALL_DEFINE1(mlockall, int, flags)
if (!ret && (flags & MCL_CURRENT))
mm_populate(0, TASK_SIZE);
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->total_vm << PAGE_SHIFT);
+
return ret;
}
@@ -798,6 +803,9 @@ int user_shm_lock(size_t size, struct user_struct *user)
get_uid(user);
user->locked_shm += locked;
allowed = 1;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ user->locked_shm << PAGE_SHIFT);
out:
spin_unlock(&shmlock_user_lock);
return allowed;
diff --git a/mm/mmap.c b/mm/mmap.c
index 305c456..c37f599 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
return -ENOMEM;
update_resource_highwatermark(RLIMIT_STACK, actual_size);
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm + grow) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/mm/mremap.c b/mm/mremap.c
index 1f157ad..f1821335 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -394,6 +394,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
*p = charged;
}
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm << PAGE_SHIFT) +
+ new_len - old_len);
return vma;
}
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 15:14 ` Oleg Nesterov
-1 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-15 15:14 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson
On 07/15, Topi Miettinen wrote:
>
> Track maximum size of locked memory, to be able to configure
> RLIMIT_MEMLOCK resource limits. The information is available
> with taskstats and cgroupstats netlink socket.
So I personally still dislike the very idea of this series... but I won't
argue if you convince maintainers.
> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
> return -ENOMEM;
>
> update_resource_highwatermark(RLIMIT_STACK, actual_size);
> + if (vma->vm_flags & VM_LOCKED)
> + update_resource_highwatermark(RLIMIT_MEMLOCK,
> + (mm->locked_vm + grow) <<
> + PAGE_SHIFT);
Btw this is not right. The same for the previous patch which tracks
RLIMIT_STACK. The "current" task can debugger/etc.
Yes, yes, this just reminds that the whole rlimit logic in this path
is broken but still...
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 15:14 ` Oleg Nesterov
0 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-15 15:14 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15, Topi Miettinen wrote:
>
> Track maximum size of locked memory, to be able to configure
> RLIMIT_MEMLOCK resource limits. The information is available
> with taskstats and cgroupstats netlink socket.
So I personally still dislike the very idea of this series... but I won't
argue if you convince maintainers.
> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
> return -ENOMEM;
>
> update_resource_highwatermark(RLIMIT_STACK, actual_size);
> + if (vma->vm_flags & VM_LOCKED)
> + update_resource_highwatermark(RLIMIT_MEMLOCK,
> + (mm->locked_vm + grow) <<
> + PAGE_SHIFT);
Btw this is not right. The same for the previous patch which tracks
RLIMIT_STACK. The "current" task can debugger/etc.
Yes, yes, this just reminds that the whole rlimit logic in this path
is broken but still...
Oleg.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 15:14 ` Oleg Nesterov
0 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-15 15:14 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15, Topi Miettinen wrote:
>
> Track maximum size of locked memory, to be able to configure
> RLIMIT_MEMLOCK resource limits. The information is available
> with taskstats and cgroupstats netlink socket.
So I personally still dislike the very idea of this series... but I won't
argue if you convince maintainers.
> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
> return -ENOMEM;
>
> update_resource_highwatermark(RLIMIT_STACK, actual_size);
> + if (vma->vm_flags & VM_LOCKED)
> + update_resource_highwatermark(RLIMIT_MEMLOCK,
> + (mm->locked_vm + grow) <<
> + PAGE_SHIFT);
Btw this is not right. The same for the previous patch which tracks
RLIMIT_STACK. The "current" task can debugger/etc.
Yes, yes, this just reminds that the whole rlimit logic in this path
is broken but still...
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
2016-07-15 15:14 ` Oleg Nesterov
(?)
@ 2016-07-15 17:39 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:39 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar
On 07/15/16 15:14, Oleg Nesterov wrote:
> On 07/15, Topi Miettinen wrote:
>>
>> Track maximum size of locked memory, to be able to configure
>> RLIMIT_MEMLOCK resource limits. The information is available
>> with taskstats and cgroupstats netlink socket.
>
> So I personally still dislike the very idea of this series... but I won't
> argue if you convince maintainers.
>
>> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
>> return -ENOMEM;
>>
>> update_resource_highwatermark(RLIMIT_STACK, actual_size);
>> + if (vma->vm_flags & VM_LOCKED)
>> + update_resource_highwatermark(RLIMIT_MEMLOCK,
>> + (mm->locked_vm + grow) <<
>> + PAGE_SHIFT);
>
> Btw this is not right. The same for the previous patch which tracks
> RLIMIT_STACK. The "current" task can debugger/etc.
acct_stack_growth() is called from expand_upwards() and
expand_downwards(). They call security_mmap_addr() and the various LSM
implementations also use current task in the checks. Are these also not
right?
>
> Yes, yes, this just reminds that the whole rlimit logic in this path
> is broken but still...
I'd be happy to fix the logic with a separate prerequisite patch and
then use the right logic for this patch, but I'm not sure I know how.
Could you elaborate a bit?
-Topi
>
> Oleg.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 17:39 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:39 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 15:14, Oleg Nesterov wrote:
> On 07/15, Topi Miettinen wrote:
>>
>> Track maximum size of locked memory, to be able to configure
>> RLIMIT_MEMLOCK resource limits. The information is available
>> with taskstats and cgroupstats netlink socket.
>
> So I personally still dislike the very idea of this series... but I won't
> argue if you convince maintainers.
>
>> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
>> return -ENOMEM;
>>
>> update_resource_highwatermark(RLIMIT_STACK, actual_size);
>> + if (vma->vm_flags & VM_LOCKED)
>> + update_resource_highwatermark(RLIMIT_MEMLOCK,
>> + (mm->locked_vm + grow) <<
>> + PAGE_SHIFT);
>
> Btw this is not right. The same for the previous patch which tracks
> RLIMIT_STACK. The "current" task can debugger/etc.
acct_stack_growth() is called from expand_upwards() and
expand_downwards(). They call security_mmap_addr() and the various LSM
implementations also use current task in the checks. Are these also not
right?
>
> Yes, yes, this just reminds that the whole rlimit logic in this path
> is broken but still...
I'd be happy to fix the logic with a separate prerequisite patch and
then use the right logic for this patch, but I'm not sure I know how.
Could you elaborate a bit?
-Topi
>
> Oleg.
>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-15 17:39 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:39 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 15:14, Oleg Nesterov wrote:
> On 07/15, Topi Miettinen wrote:
>>
>> Track maximum size of locked memory, to be able to configure
>> RLIMIT_MEMLOCK resource limits. The information is available
>> with taskstats and cgroupstats netlink socket.
>
> So I personally still dislike the very idea of this series... but I won't
> argue if you convince maintainers.
>
>> @@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct vm_area_struct *vma, unsigned long size, uns
>> return -ENOMEM;
>>
>> update_resource_highwatermark(RLIMIT_STACK, actual_size);
>> + if (vma->vm_flags & VM_LOCKED)
>> + update_resource_highwatermark(RLIMIT_MEMLOCK,
>> + (mm->locked_vm + grow) <<
>> + PAGE_SHIFT);
>
> Btw this is not right. The same for the previous patch which tracks
> RLIMIT_STACK. The "current" task can debugger/etc.
acct_stack_growth() is called from expand_upwards() and
expand_downwards(). They call security_mmap_addr() and the various LSM
implementations also use current task in the checks. Are these also not
right?
>
> Yes, yes, this just reminds that the whole rlimit logic in this path
> is broken but still...
I'd be happy to fix the logic with a separate prerequisite patch and
then use the right logic for this patch, but I'm not sure I know how.
Could you elaborate a bit?
-Topi
>
> Oleg.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
2016-07-15 17:39 ` Topi Miettinen
(?)
@ 2016-07-18 15:38 ` Oleg Nesterov
-1 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-18 15:38 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson
On 07/15, Topi Miettinen wrote:
>
> On 07/15/16 15:14, Oleg Nesterov wrote:
> >
> > Btw this is not right. The same for the previous patch which tracks
> > RLIMIT_STACK. The "current" task can debugger/etc.
>
> acct_stack_growth() is called from expand_upwards() and
> expand_downwards(). They call security_mmap_addr() and the various LSM
> implementations also use current task in the checks. Are these also not
> right?
Just suppose that the stack grows because you read/write to /proc/pid/mem.
> > Yes, yes, this just reminds that the whole rlimit logic in this path
> > is broken but still...
>
> I'd be happy to fix the logic with a separate prerequisite patch and
> then use the right logic for this patch, but I'm not sure I know how.
> Could you elaborate a bit?
If only I Knew how to fix this ;) I mean, if only I could suggest a
simple fix. Because IMHO we do not really care, rlimts are obsolete.
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-18 15:38 ` Oleg Nesterov
0 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-18 15:38 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15, Topi Miettinen wrote:
>
> On 07/15/16 15:14, Oleg Nesterov wrote:
> >
> > Btw this is not right. The same for the previous patch which tracks
> > RLIMIT_STACK. The "current" task can debugger/etc.
>
> acct_stack_growth() is called from expand_upwards() and
> expand_downwards(). They call security_mmap_addr() and the various LSM
> implementations also use current task in the checks. Are these also not
> right?
Just suppose that the stack grows because you read/write to /proc/pid/mem.
> > Yes, yes, this just reminds that the whole rlimit logic in this path
> > is broken but still...
>
> I'd be happy to fix the logic with a separate prerequisite patch and
> then use the right logic for this patch, but I'm not sure I know how.
> Could you elaborate a bit?
If only I Knew how to fix this ;) I mean, if only I could suggest a
simple fix. Because IMHO we do not really care, rlimts are obsolete.
Oleg.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 09/14] resource limits: track highwater mark of locked memory
@ 2016-07-18 15:38 ` Oleg Nesterov
0 siblings, 0 replies; 95+ messages in thread
From: Oleg Nesterov @ 2016-07-18 15:38 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Tony Luck, Fenghua Yu, Paolo Bonzini,
Radim Krčmář,
Alexander Graf, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Doug Ledford, Sean Hefty, Hal Rosenstock,
Mike Marciniszyn, Dennis Dalessandro, Christian Benvenuti,
Dave Goodell, Sudeep Dutt, Ashutosh Dixit, Alex Williamson,
Alexei Starovoitov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Andrew Morton,
Jiri Slaby, Konstantin Khlebnikov, Cyrill Gorcunov, Dave Hansen,
Thomas Gleixner, Greg Kroah-Hartman, Dan Carpenter,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov, Eric B Munson,
Alexey Klimov, Andrea Arcangeli, Chen Gang, Andrey Ryabinin,
David Rientjes, Hugh Dickins, Alexander Kuleshov,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15, Topi Miettinen wrote:
>
> On 07/15/16 15:14, Oleg Nesterov wrote:
> >
> > Btw this is not right. The same for the previous patch which tracks
> > RLIMIT_STACK. The "current" task can debugger/etc.
>
> acct_stack_growth() is called from expand_upwards() and
> expand_downwards(). They call security_mmap_addr() and the various LSM
> implementations also use current task in the checks. Are these also not
> right?
Just suppose that the stack grows because you read/write to /proc/pid/mem.
> > Yes, yes, this just reminds that the whole rlimit logic in this path
> > is broken but still...
>
> I'd be happy to fix the logic with a separate prerequisite patch and
> then use the right logic for this patch, but I'm not sure I know how.
> Could you elaborate a bit?
If only I Knew how to fix this ;) I mean, if only I could suggest a
simple fix. Because IMHO we do not really care, rlimts are obsolete.
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH 09/14] resource limits: track highwater mark of locked memory
2016-07-15 10:35 ` Topi Miettinen
` (2 preceding siblings ...)
(?)
@ 2016-07-15 17:45 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:45 UTC (permalink / raw)
To: linux-kernel
Track maximum size of locked memory, to be able to configure
RLIMIT_MEMLOCK resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
(Resending to lkml due to header size limits)
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 ++
arch/powerpc/mm/mmu_context_iommu.c | 2 ++
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 ++
drivers/infiniband/hw/qib/qib_user_pages.c | 2 ++
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 ++
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 +++++
kernel/bpf/syscall.c | 8 ++++++++
kernel/events/core.c | 1 +
mm/mlock.c | 8 ++++++++
mm/mmap.c | 4 ++++
mm/mremap.c | 4 ++++
15 files changed, 45 insertions(+)
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 2436ad5..7c6ae72 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2341,6 +2341,7 @@ pfm_smpl_buffer_alloc(struct task_struct *task,
struct file *filp, pfm_context_t
ctx->ctx_smpl_vaddr = (void *)vma->vm_start;
*(unsigned long *)user_vaddr = vma->vm_start;
+ task_update_resource_highwatermark(task, RLIMIT_MEMLOCK, size);
return 0;
error:
diff --git a/arch/powerpc/kvm/book3s_64_vio.c
b/arch/powerpc/kvm/book3s_64_vio.c
index 18cf6d1..40ea177 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -71,6 +71,8 @@ static long kvmppc_account_memlimit(unsigned long
stt_pages, bool inc)
ret = -ENOMEM;
else
current->mm->locked_vm += stt_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
stt_pages = current->mm->locked_vm;
diff --git a/arch/powerpc/mm/mmu_context_iommu.c
b/arch/powerpc/mm/mmu_context_iommu.c
index da6a216..8c6bcbf 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -46,6 +46,8 @@ static long mm_iommu_adjust_locked_vm(struct mm_struct
*mm,
ret = -ENOMEM;
else
mm->locked_vm += npages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ locked << PAGE_SHIFT);
} else {
if (WARN_ON_ONCE(npages > mm->locked_vm))
npages = mm->locked_vm;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index fe4d2e1..3c454eb 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -224,6 +224,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext
*context, unsigned long addr,
ret = 0;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
out:
if (ret < 0) {
if (need_release)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index 88e10b5f..ca55f8c 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -111,6 +111,8 @@ int hfi1_acquire_user_pages(unsigned long vaddr,
size_t npages, bool writable,
down_write(¤t->mm->mmap_sem);
current->mm->pinned_vm += ret;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index 2d2b94f..3a103c4 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -74,6 +74,8 @@ static int __qib_get_user_pages(unsigned long
start_page, size_t num_pages,
}
current->mm->pinned_vm += num_pages;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->pinned_vm << PAGE_SHIFT);
ret = 0;
goto bail;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index a0b6ebe..6180654 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -178,6 +178,8 @@ static int usnic_uiom_get_pages(unsigned long addr,
size_t size, int writable,
ret = 0;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
out:
if (ret < 0)
usnic_uiom_put_pages(chunk_list, 0);
diff --git a/drivers/misc/mic/scif/scif_rma.c
b/drivers/misc/mic/scif/scif_rma.c
index e0203b1..acb970a 100644
--- a/drivers/misc/mic/scif/scif_rma.c
+++ b/drivers/misc/mic/scif/scif_rma.c
@@ -306,6 +306,7 @@ static inline int __scif_check_inc_pinned_vm(struct
mm_struct *mm,
return -ENOMEM;
}
mm->pinned_vm = locked;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
return 0;
}
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 80378dd..13ee9e9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -55,6 +55,8 @@ static long try_increment_locked_vm(long npages)
rlimit(RLIMIT_MEMLOCK),
ret ? " - exceeded" : "");
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
up_write(¤t->mm->mmap_sem);
return ret;
diff --git a/drivers/vfio/vfio_iommu_type1.c
b/drivers/vfio/vfio_iommu_type1.c
index 2ba1942..e868ae5 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -145,6 +145,8 @@ static void vfio_lock_acct_bg(struct work_struct *work)
mm = vwork->mm;
down_write(&mm->mmap_sem);
mm->locked_vm += vwork->npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm << PAGE_SHIFT);
up_write(&mm->mmap_sem);
mmput(mm);
kfree(vwork);
@@ -160,6 +162,9 @@ static void vfio_lock_acct(long npage)
if (down_write_trylock(¤t->mm->mmap_sem)) {
current->mm->locked_vm += npage;
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->locked_vm <<
+ PAGE_SHIFT);
up_write(¤t->mm->mmap_sem);
return;
}
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 46ecce4..0efa1c3 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -76,6 +76,10 @@ static int bpf_map_charge_memlock(struct bpf_map *map)
return -EPERM;
}
map->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
@@ -601,6 +605,10 @@ static int bpf_prog_charge_memlock(struct bpf_prog
*prog)
return -EPERM;
}
prog->aux->user = user;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ atomic_long_read(&user->locked_vm) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 43d43a2d..4b8b143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5096,6 +5096,7 @@ accounting:
if (!ret)
rb->aux_mmap_locked = extra;
}
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
unlock:
if (!ret) {
diff --git a/mm/mlock.c b/mm/mlock.c
index ef8dc9f..eb45857 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -648,6 +648,8 @@ static __must_check int do_mlock(unsigned long
start, size_t len, vm_flags_t fla
if (error)
return error;
+ update_resource_highwatermark(RLIMIT_MEMLOCK, locked << PAGE_SHIFT);
+
error = __mm_populate(start, len, 0);
if (error)
return __mlock_posix_error_return(error);
@@ -761,6 +763,9 @@ SYSCALL_DEFINE1(mlockall, int, flags)
if (!ret && (flags & MCL_CURRENT))
mm_populate(0, TASK_SIZE);
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ current->mm->total_vm << PAGE_SHIFT);
+
return ret;
}
@@ -798,6 +803,9 @@ int user_shm_lock(size_t size, struct user_struct
*user)
get_uid(user);
user->locked_shm += locked;
allowed = 1;
+
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ user->locked_shm << PAGE_SHIFT);
out:
spin_unlock(&shmlock_user_lock);
return allowed;
diff --git a/mm/mmap.c b/mm/mmap.c
index 305c456..c37f599 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2020,6 +2020,10 @@ static int acct_stack_growth(struct
vm_area_struct *vma, unsigned long size, uns
return -ENOMEM;
update_resource_highwatermark(RLIMIT_STACK, actual_size);
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm + grow) <<
+ PAGE_SHIFT);
return 0;
}
diff --git a/mm/mremap.c b/mm/mremap.c
index 1f157ad..f1821335 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -394,6 +394,10 @@ static struct vm_area_struct
*vma_to_resize(unsigned long addr,
*p = charged;
}
+ if (vma->vm_flags & VM_LOCKED)
+ update_resource_highwatermark(RLIMIT_MEMLOCK,
+ (mm->locked_vm << PAGE_SHIFT) +
+ new_len - old_len);
return vma;
}
-- 2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 10/14] resource limits: track highwater mark of address space size
2016-07-15 10:35 ` Topi Miettinen
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Andrew Morton, Oleg Nesterov, Kirill A. Shutemov,
Chen Gang, Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
Andrey Ryabinin, David Rientjes, Vlastimil Babka, Hugh Dickins,
Alexander Kuleshov, open list:MEMORY MANAGEMENT
Track maximum size of address space, to be able to configure
RLIMIT_AS resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
mm/mmap.c | 4 ++++
mm/mremap.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index c37f599..ded2f8d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2707,6 +2707,9 @@ static int do_brk(unsigned long addr, unsigned long len)
out:
perf_event_mmap(vma);
mm->total_vm += len >> PAGE_SHIFT;
+
+ update_resource_highwatermark(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
+
mm->data_vm += len >> PAGE_SHIFT;
if (flags & VM_LOCKED)
mm->locked_vm += (len >> PAGE_SHIFT);
@@ -2927,6 +2930,7 @@ bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
{
mm->total_vm += npages;
+ update_resource_highwatermark(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
if (is_exec_mapping(flags))
mm->exec_vm += npages;
diff --git a/mm/mremap.c b/mm/mremap.c
index f1821335..aa717d0 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -398,6 +398,9 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
update_resource_highwatermark(RLIMIT_MEMLOCK,
(mm->locked_vm << PAGE_SHIFT) +
new_len - old_len);
+ update_resource_highwatermark(RLIMIT_AS, (mm->total_vm << PAGE_SHIFT) +
+ new_len - old_len);
+
return vma;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 10/14] resource limits: track highwater mark of address space size
@ 2016-07-15 10:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Andrew Morton, Oleg Nesterov, Kirill A. Shutemov,
Chen Gang, Michal Hocko, Konstantin Khlebnikov, Andrea Arcangeli,
Andrey Ryabinin, David Rientjes, Vlastimil Babka, Hugh Dickins,
Alexander Kuleshov, open list:MEMORY MANAGEMENT
Track maximum size of address space, to be able to configure
RLIMIT_AS resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
mm/mmap.c | 4 ++++
mm/mremap.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index c37f599..ded2f8d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2707,6 +2707,9 @@ static int do_brk(unsigned long addr, unsigned long len)
out:
perf_event_mmap(vma);
mm->total_vm += len >> PAGE_SHIFT;
+
+ update_resource_highwatermark(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
+
mm->data_vm += len >> PAGE_SHIFT;
if (flags & VM_LOCKED)
mm->locked_vm += (len >> PAGE_SHIFT);
@@ -2927,6 +2930,7 @@ bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
{
mm->total_vm += npages;
+ update_resource_highwatermark(RLIMIT_AS, mm->total_vm << PAGE_SHIFT);
if (is_exec_mapping(flags))
mm->exec_vm += npages;
diff --git a/mm/mremap.c b/mm/mremap.c
index f1821335..aa717d0 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -398,6 +398,9 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
update_resource_highwatermark(RLIMIT_MEMLOCK,
(mm->locked_vm << PAGE_SHIFT) +
new_len - old_len);
+ update_resource_highwatermark(RLIMIT_AS, (mm->total_vm << PAGE_SHIFT) +
+ new_len - old_len);
+
return vma;
}
--
2.8.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 95+ messages in thread
* [PATCH 11/14] resource limits: track highwater mark of number of pending signals
2016-07-15 10:35 ` Topi Miettinen
` (13 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Andrew Morton, Ingo Molnar, Oleg Nesterov,
Amanieu d'Antras, Stas Sergeev, Andy Lutomirski,
Wang Xiaoqiang, Sasha Levin, Dave Hansen
Track maximum number of pending signals, to be able to configure
RLIMIT_SIGPENDING resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
kernel/signal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 96e9bc4..670d609 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -387,6 +387,8 @@ __sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimi
INIT_LIST_HEAD(&q->list);
q->flags = 0;
q->user = user;
+ task_update_resource_highwatermark(t, RLIMIT_SIGPENDING,
+ atomic_read(&user->sigpending));
}
return q;
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 12/14] resource limits: track highwater mark of size of message queues
2016-07-15 10:35 ` Topi Miettinen
` (14 preceding siblings ...)
(?)
@ 2016-07-15 10:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:35 UTC (permalink / raw)
To: linux-kernel
Cc: Topi Miettinen, Michal Hocko, Andrew Morton, Marcus Gelderie,
Doug Ledford, Al Viro, Kirill A. Shutemov, Vladimir Davydov
Track maximum size of message queues, to be able to configure
RLIMIT_MSGQUEUE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
ipc/mqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index ade739f..037ea47 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -287,6 +287,7 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
/* all is ok */
info->user = get_uid(u);
+ update_resource_highwatermark(RLIMIT_MSGQUEUE, u->mq_bytes);
} else if (S_ISDIR(mode)) {
inc_nlink(inode);
/* Some things misbehave if size == 0 on a directory */
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 13/14] resource limits: track highwater mark of niceness
2016-07-15 10:35 ` Topi Miettinen
` (15 preceding siblings ...)
(?)
@ 2016-07-15 10:36 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Topi Miettinen, Ingo Molnar, Peter Zijlstra
Track maximum nice priority, to be able to configure
RLIMIT_NICE resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 97ee9ac..da32bcd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3693,6 +3693,9 @@ void set_user_nice(struct task_struct *p, long nice)
if (delta < 0 || (delta > 0 && task_running(rq, p)))
resched_curr(rq);
}
+ task_update_resource_highwatermark(p, RLIMIT_NICE,
+ nice_to_rlimit(nice));
+
out_unlock:
task_rq_unlock(rq, p, &rf);
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* [PATCH 14/14] resource limits: track highwater mark of RT priority
2016-07-15 10:35 ` Topi Miettinen
` (16 preceding siblings ...)
(?)
@ 2016-07-15 10:36 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 10:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Topi Miettinen, Ingo Molnar, Peter Zijlstra
Track maximum RT priority, to be able to configure
RLIMIT_RTPRIO resource limits. The information is available
with taskstats and cgroupstats netlink socket.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index da32bcd..bb08b43 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4221,6 +4221,9 @@ change:
balance_callback(rq);
preempt_enable();
+ task_update_resource_highwatermark(p, RLIMIT_RTPRIO,
+ attr->sched_priority);
+
return 0;
}
--
2.8.1
^ permalink raw reply related [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 12:43 ` Peter Zijlstra
-1 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 12:43 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
And how is that useful? Setting things to the high watermark is
basically the same as not setting the limit at all.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 12:43 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 12:43 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
And how is that useful? Setting things to the high watermark is
basically the same as not setting the limit at all.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 12:43 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 12:43 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
And how is that useful? Setting things to the high watermark is
basically the same as not setting the limit at all.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 12:43 ` Peter Zijlstra
(?)
@ 2016-07-15 13:52 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 13:52 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt
On 07/15/16 12:43, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>
> And how is that useful? Setting things to the high watermark is
> basically the same as not setting the limit at all.
What else would you use, too small limits?
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:52 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 13:52 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 12:43, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>
> And how is that useful? Setting things to the high watermark is
> basically the same as not setting the limit at all.
What else would you use, too small limits?
-Topi
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:52 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 13:52 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 12:43, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>
> And how is that useful? Setting things to the high watermark is
> basically the same as not setting the limit at all.
What else would you use, too small limits?
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:52 ` Topi Miettinen
` (2 preceding siblings ...)
(?)
@ 2016-07-15 13:59 ` Peter Zijlstra
-1 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 13:59 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt
On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including capabilities,
> >> cgroups and resource limits. However, there are far fewer ways to find out
> >> useful values for the limits, except blind trial and error.
> >>
> >> This patch series attempts to fix that by giving at least a nice starting
> >> point from the highwater mark values of the resources in question.
> >> I looked where each limit is checked and added a call to update the mark
> >> nearby.
> >
> > And how is that useful? Setting things to the high watermark is
> > basically the same as not setting the limit at all.
>
> What else would you use, too small limits?
That question doesn't make sense.
What's the point of setting a limit if it ends up being the same as
no-limit (aka unlimited).
If you cannot explain; and you have not so far; what use these values
are, why would we look at the patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:59 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 13:59 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including capabilities,
> >> cgroups and resource limits. However, there are far fewer ways to find out
> >> useful values for the limits, except blind trial and error.
> >>
> >> This patch series attempts to fix that by giving at least a nice starting
> >> point from the highwater mark values of the resources in question.
> >> I looked where each limit is checked and added a call to update the mark
> >> nearby.
> >
> > And how is that useful? Setting things to the high watermark is
> > basically the same as not setting the limit at all.
>
> What else would you use, too small limits?
That question doesn't make sense.
What's the point of setting a limit if it ends up being the same as
no-limit (aka unlimited).
If you cannot explain; and you have not so far; what use these values
are, why would we look at the patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:59 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 13:59 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including capabilities,
> >> cgroups and resource limits. However, there are far fewer ways to find out
> >> useful values for the limits, except blind trial and error.
> >>
> >> This patch series attempts to fix that by giving at least a nice starting
> >> point from the highwater mark values of the resources in question.
> >> I looked where each limit is checked and added a call to update the mark
> >> nearby.
> >
> > And how is that useful? Setting things to the high watermark is
> > basically the same as not setting the limit at all.
>
> What else would you use, too small limits?
That question doesn't make sense.
What's the point of setting a limit if it ends up being the same as
no-limit (aka unlimited).
If you cannot explain; and you have not so far; what use these values
are, why would we look at the patches.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:59 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 13:59 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including capabilities,
> >> cgroups and resource limits. However, there are far fewer ways to find out
> >> useful values for the limits, except blind trial and error.
> >>
> >> This patch series attempts to fix that by giving at least a nice starting
> >> point from the highwater mark values of the resources in question.
> >> I looked where each limit is checked and added a call to update the mark
> >> nearby.
> >
> > And how is that useful? Setting things to the high watermark is
> > basically the same as not setting the limit at all.
>
> What else would you use, too small limits?
That question doesn't make sense.
What's the point of setting a limit if it ends up being the same as
no-limit (aka unlimited).
If you cannot explain; and you have not so far; what use these values
are, why would we look at the patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:59 ` Peter Zijlstra
0 siblings, 0 replies; 95+ messages in thread
From: Peter Zijlstra @ 2016-07-15 13:59 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including capabilities,
> >> cgroups and resource limits. However, there are far fewer ways to find out
> >> useful values for the limits, except blind trial and error.
> >>
> >> This patch series attempts to fix that by giving at least a nice starting
> >> point from the highwater mark values of the resources in question.
> >> I looked where each limit is checked and added a call to update the mark
> >> nearby.
> >
> > And how is that useful? Setting things to the high watermark is
> > basically the same as not setting the limit at all.
>
> What else would you use, too small limits?
That question doesn't make sense.
What's the point of setting a limit if it ends up being the same as
no-limit (aka unlimited).
If you cannot explain; and you have not so far; what use these values
are, why would we look at the patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:59 ` Peter Zijlstra
(?)
(?)
@ 2016-07-15 16:57 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
On 07/15/16 13:59, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>
>>> And how is that useful? Setting things to the high watermark is
>>> basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
> That question doesn't make sense.
>
> What's the point of setting a limit if it ends up being the same as
> no-limit (aka unlimited).
Having a limit is not the same as not having any limits at all. You're
in a way right that good limits don't affect the program normally. But
they can make a difference if the flow is not normal. For example a
successful exploit or a memory leak bug could cause RLIMIT_AS to trigger.
>
> If you cannot explain; and you have not so far; what use these values
> are, why would we look at the patches.
>
The use case is to allow system administrators, distro maintainers and
developers to configure systems to use the resource limits. The limits
are not very useful right now, as there is no way to figure out what
values to use. There are a few /proc files to look, for example current
number of file descriptors (for RLIMIT_NOFILE) could be counted via
/proc/pid/fd. But now there is no way to know if there were more in use
at some point. Likewise, a program can use more address space when you
are not looking. The source code does not tell these things explicitly.
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 16:57 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 13:59, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>
>>> And how is that useful? Setting things to the high watermark is
>>> basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
> That question doesn't make sense.
>
> What's the point of setting a limit if it ends up being the same as
> no-limit (aka unlimited).
Having a limit is not the same as not having any limits at all. You're
in a way right that good limits don't affect the program normally. But
they can make a difference if the flow is not normal. For example a
successful exploit or a memory leak bug could cause RLIMIT_AS to trigger.
>
> If you cannot explain; and you have not so far; what use these values
> are, why would we look at the patches.
>
The use case is to allow system administrators, distro maintainers and
developers to configure systems to use the resource limits. The limits
are not very useful right now, as there is no way to figure out what
values to use. There are a few /proc files to look, for example current
number of file descriptors (for RLIMIT_NOFILE) could be counted via
/proc/pid/fd. But now there is no way to know if there were more in use
at some point. Likewise, a program can use more address space when you
are not looking. The source code does not tell these things explicitly.
-Topi
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 16:57 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 13:59, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>
>>> And how is that useful? Setting things to the high watermark is
>>> basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
> That question doesn't make sense.
>
> What's the point of setting a limit if it ends up being the same as
> no-limit (aka unlimited).
Having a limit is not the same as not having any limits at all. You're
in a way right that good limits don't affect the program normally. But
they can make a difference if the flow is not normal. For example a
successful exploit or a memory leak bug could cause RLIMIT_AS to trigger.
>
> If you cannot explain; and you have not so far; what use these values
> are, why would we look at the patches.
>
The use case is to allow system administrators, distro maintainers and
developers to configure systems to use the resource limits. The limits
are not very useful right now, as there is no way to figure out what
values to use. There are a few /proc files to look, for example current
number of file descriptors (for RLIMIT_NOFILE) could be counted via
/proc/pid/fd. But now there is no way to know if there were more in use
at some point. Likewise, a program can use more address space when you
are not looking. The source code does not tell these things explicitly.
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 16:57 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
On 07/15/16 13:59, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>
>>> And how is that useful? Setting things to the high watermark is
>>> basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
> That question doesn't make sense.
>
> What's the point of setting a limit if it ends up being the same as
> no-limit (aka unlimited).
Having a limit is not the same as not having any limits at all. You're
in a way right that good limits don't affect the program normally. But
they can make a difference if the flow is not normal. For example a
successful exploit or a memory leak bug could cause RLIMIT_AS to trigger.
>
> If you cannot explain; and you have not so far; what use these values
> are, why would we look at the patches.
>
The use case is to allow system administrators, distro maintainers and
developers to configure systems to use the resource limits. The limits
are not very useful right now, as there is no way to figure out what
values to use. There are a few /proc files to look, for example current
number of file descriptors (for RLIMIT_NOFILE) could be counted via
/proc/pid/fd. But now there is no way to know if there were more in use
at some point. Likewise, a program can use more address space when you
are not looking. The source code does not tell these things explicitly.
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:59 ` Peter Zijlstra
` (4 preceding siblings ...)
(?)
@ 2016-07-15 20:54 ` H. Peter Anvin
-1 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:59 ` Peter Zijlstra
(?)
(?)
@ 2016-07-15 20:54 ` H. Peter Anvin
-1 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li.Zefan
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 20:54 ` H. Peter Anvin
0 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li.Zefan
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 20:54 ` H. Peter Anvin
0 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li.Zefan
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 20:54 ` H. Peter Anvin
0 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia6
4@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 20:54 ` H. Peter Anvin
` (2 preceding siblings ...)
(?)
@ 2016-07-18 13:00 ` Austin S. Hemmelgarn
-1 siblings, 0 replies; 95+ messages in thread
From: Austin S. Hemmelgarn @ 2016-07-18 13:00 UTC (permalink / raw)
To: H. Peter Anvin, Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li.Zefan
On 2016-07-15 16:54, H. Peter Anvin wrote:
> On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>>> Hello,
>>>>>
>>>>> There are many basic ways to control processes, including
>> capabilities,
>>>>> cgroups and resource limits. However, there are far fewer ways to
>> find out
>>>>> useful values for the limits, except blind trial and error.
>>>>>
>>>>> This patch series attempts to fix that by giving at least a nice
>> starting
>>>>> point from the highwater mark values of the resources in question.
>>>>> I looked where each limit is checked and added a call to update
>> the mark
>>>>> nearby.
>>>>
>>>> And how is that useful? Setting things to the high watermark is
>>>> basically the same as not setting the limit at all.
>>>
>>> What else would you use, too small limits?
>>
>> That question doesn't make sense.
>>
>> What's the point of setting a limit if it ends up being the same as
>> no-limit (aka unlimited).
>>
>> If you cannot explain; and you have not so far; what use these values
>> are, why would we look at the patches.
>
> One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
>
Additionally, there are quite a few applications which don't gracefully
handle memory allocation or process creation failures, either hanging,
constantly retrying, or just dying when this happens. For such an
application, you have to set the limit to the high watermark if you want
them limited at all, otherwise they don't work. A classic example of
this is the official client for Dropbox. If it can't start up all the
insane number of threads it thinks it needs, then it just hangs.
However, it's also a network service, and therefore is a reasonable
target for hackers, so it makes sense to try and limit it. I've run
into similar issues with quite a few 'desktop' services, both open and
closed source.
Looking at this another way, this is most useful for things that have a
deterministic maximum resource usage under regular use, not something
like a forking server which has a functionally unbounded maximum
resource usage.
^ permalink raw reply [flat|nested] 95+ messages in thread
[parent not found: <20160715135956.GA3115-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>]
* Re: [PATCH 00/14] Present useful limits to user (v2)
[not found] ` <20160715135956.GA3115-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
@ 2016-07-15 20:54 ` H. Peter Anvin
2016-07-15 20:54 ` H. Peter Anvin
1 sibling, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet, Tony Luck,
Fenghua Yu, Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
<lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,Arnaldo Carvalho de Melo <acme-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,Alexander Shishkin <alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>,Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,Konstantin Khlebnikov <koct9i-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Jiri Slaby <jslaby-AlSwsSmVLrQ@public.gmane.org>,Cyrill Gorcunov <gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>,Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>,Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,"Kirill A. Shutemov" <kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
,Marcus Gelderie <redmnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>,Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Andrea Arcangeli <aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,!
"Eric W.
Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Stas Sergeev <stsp-cmBhpYW9OiY@public.gmane.org>,Amanieu d'Antras <amanieu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,Wang Xiaoqiang <wangxq10-Uu6Fka/qEtMnDS1+zs4M5A@public.gmane.org>,Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>,Mateusz Guzik <mguzik-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Alex Thorlton <athorlton-sJ/iWh9BUns@public.gmane.org>,Ben Segall <bsegall-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Eric B Munson <emunson-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>,Alexey Klimov <klimov.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Chen Gang <gang.chen.5i5j-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,Alexander Kuleshov <kuleshovmail-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,"open list:DOCUMENTATION" <linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia6
4@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:MEMORY MANAGEMENT" <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
[not found] ` <20160715135956.GA3115-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-07-15 20:54 ` H. Peter Anvin
@ 2016-07-15 20:54 ` H. Peter Anvin
1 sibling, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet, Tony Luck,
Fenghua Yu, Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex
<lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,Arnaldo Carvalho de Melo <acme-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,Alexander Shishkin <alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>,Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,Konstantin Khlebnikov <koct9i-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Jiri Slaby <jslaby-AlSwsSmVLrQ@public.gmane.org>,Cyrill Gorcunov <gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>,Vlastimil Babka <vbabka-AlSwsSmVLrQ@public.gmane.org>,Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,"Kirill A. Shutemov" <kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
,Marcus Gelderie <redmnic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>,Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Andrea Arcangeli <aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,!
"Eric W.
Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Stas Sergeev <stsp-cmBhpYW9OiY@public.gmane.org>,Amanieu d'Antras <amanieu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,Wang Xiaoqiang <wangxq10-Uu6Fka/qEtMnDS1+zs4M5A@public.gmane.org>,Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>,Mateusz Guzik <mguzik-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Alex Thorlton <athorlton-sJ/iWh9BUns@public.gmane.org>,Ben Segall <bsegall-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,Eric B Munson <emunson-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>,Alexey Klimov <klimov.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Chen Gang <gang.chen.5i5j-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,Alexander Kuleshov <kuleshovmail-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,"open list:DOCUMENTATION" <linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia6
4@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,"open list:MEMORY MANAGEMENT" <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:59 ` Peter Zijlstra
` (7 preceding siblings ...)
(?)
@ 2016-07-15 20:54 ` H. Peter Anvin
-1 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia6
4@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:59 ` Peter Zijlstra
` (8 preceding siblings ...)
(?)
@ 2016-07-15 20:54 ` H. Peter Anvin
-1 siblings, 0 replies; 95+ messages in thread
From: H. Peter Anvin @ 2016-07-15 20:54 UTC (permalink / raw)
To: Peter Zijlstra, Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Kr??m????,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex
<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
"Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia6
4@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
(32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>> On 07/15/16 12:43, Peter Zijlstra wrote:
>> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> >> Hello,
>> >>
>> >> There are many basic ways to control processes, including
>capabilities,
>> >> cgroups and resource limits. However, there are far fewer ways to
>find out
>> >> useful values for the limits, except blind trial and error.
>> >>
>> >> This patch series attempts to fix that by giving at least a nice
>starting
>> >> point from the highwater mark values of the resources in question.
>> >> I looked where each limit is checked and added a call to update
>the mark
>> >> nearby.
>> >
>> > And how is that useful? Setting things to the high watermark is
>> > basically the same as not setting the limit at all.
>>
>> What else would you use, too small limits?
>
>That question doesn't make sense.
>
>What's the point of setting a limit if it ends up being the same as
>no-limit (aka unlimited).
>
>If you cannot explain; and you have not so far; what use these values
>are, why would we look at the patches.
One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 13:04 ` Balbir Singh
-1 siblings, 0 replies; 95+ messages in thread
From: Balbir Singh @ 2016-07-15 13:04 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
Does this mean that rlimit_data and rlimit_stack should be set to the
values as specified by the data above?
Do we expect a smart user space daemon to then tweak the RLIMIT values?
Balbir Singh.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:04 ` Balbir Singh
0 siblings, 0 replies; 95+ messages in thread
From: Balbir Singh @ 2016-07-15 13:04 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Richard Weinberger, Wang Xiaoqiang,
Helge Deller, Mateusz Guzik, Alex Thorlton, Ben Segall,
John Stultz, Rik van Riel, Eric B Munson, Alexey Klimov,
Chen Gang, Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
Does this mean that rlimit_data and rlimit_stack should be set to the
values as specified by the data above?
Do we expect a smart user space daemon to then tweak the RLIMIT values?
Balbir Singh.
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 13:04 ` Balbir Singh
0 siblings, 0 replies; 95+ messages in thread
From: Balbir Singh @ 2016-07-15 13:04 UTC (permalink / raw)
To: Topi Miettinen
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Richard Weinberger, Wang Xiaoqiang,
Helge Deller, Mateusz Guzik, Alex Thorlton, Ben Segall,
John Stultz, Rik van Riel, Eric B Munson, Alexey Klimov,
Chen Gang, Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
Does this mean that rlimit_data and rlimit_stack should be set to the
values as specified by the data above?
Do we expect a smart user space daemon to then tweak the RLIMIT values?
Balbir Singh.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 13:04 ` Balbir Singh
(?)
@ 2016-07-15 16:35 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:35 UTC (permalink / raw)
To: bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt
On 07/15/16 13:04, Balbir Singh wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>
> Does this mean that rlimit_data and rlimit_stack should be set to the
> values as specified by the data above?
My plan is that either system administrator, distro maintainer or even
upstream developer can get reasonable values for the limits. They may
still be wrong, but things would be better than without any help to
configure the system.
>
> Do we expect a smart user space daemon to then tweak the RLIMIT values?
Someone could write an autotuning daemon that checks if the system has
changed (for example due to upgrade) and then run some tests to
reconfigure the system. But the limits are a bit too fragile, or rather,
applications can't handle failure, so I don't know if that would really
work.
-Topi
>
> Balbir Singh.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 16:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:35 UTC (permalink / raw)
To: bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 13:04, Balbir Singh wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>
> Does this mean that rlimit_data and rlimit_stack should be set to the
> values as specified by the data above?
My plan is that either system administrator, distro maintainer or even
upstream developer can get reasonable values for the limits. They may
still be wrong, but things would be better than without any help to
configure the system.
>
> Do we expect a smart user space daemon to then tweak the RLIMIT values?
Someone could write an autotuning daemon that checks if the system has
changed (for example due to upgrade) and then run some tests to
reconfigure the system. But the limits are a bit too fragile, or rather,
applications can't handle failure, so I don't know if that would really
work.
-Topi
>
> Balbir Singh.
>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 16:35 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 16:35 UTC (permalink / raw)
To: bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 13:04, Balbir Singh wrote:
> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>
> Does this mean that rlimit_data and rlimit_stack should be set to the
> values as specified by the data above?
My plan is that either system administrator, distro maintainer or even
upstream developer can get reasonable values for the limits. They may
still be wrong, but things would be better than without any help to
configure the system.
>
> Do we expect a smart user space daemon to then tweak the RLIMIT values?
Someone could write an autotuning daemon that checks if the system has
changed (for example due to upgrade) and then run some tests to
reconfigure the system. But the limits are a bit too fragile, or rather,
applications can't handle failure, so I don't know if that would really
work.
-Topi
>
> Balbir Singh.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 16:35 ` Topi Miettinen
@ 2016-07-18 22:05 ` Doug Ledford
-1 siblings, 0 replies; 95+ messages in thread
From: Doug Ledford @ 2016-07-18 22:05 UTC (permalink / raw)
To: Topi Miettinen, bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti
[-- Attachment #1.1: Type: text/plain, Size: 8959 bytes --]
On 7/15/2016 12:35 PM, Topi Miettinen wrote:
> On 07/15/16 13:04, Balbir Singh wrote:
>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>> Hello,
>>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer ways to find out
>>> useful values for the limits, except blind trial and error.
>>>
>>> This patch series attempts to fix that by giving at least a nice starting
>>> point from the highwater mark values of the resources in question.
>>> I looked where each limit is checked and added a call to update the mark
>>> nearby.
>>>
>>> Example run of program from Documentation/accounting/getdelauys.c:
>>>
>>> ./getdelays -R -p `pidof smartd`
>>> printing resource accounting
>>> RLIMIT_CPU=0
>>> RLIMIT_FSIZE=0
>>> RLIMIT_DATA=18198528
>>> RLIMIT_STACK=135168
>>> RLIMIT_CORE=0
>>> RLIMIT_RSS=0
>>> RLIMIT_NPROC=1
>>> RLIMIT_NOFILE=55
>>> RLIMIT_MEMLOCK=0
>>> RLIMIT_AS=130879488
>>> RLIMIT_LOCKS=0
>>> RLIMIT_SIGPENDING=0
>>> RLIMIT_MSGQUEUE=0
>>> RLIMIT_NICE=0
>>> RLIMIT_RTPRIO=0
>>> RLIMIT_RTTIME=0
>>>
>>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>>> printing resource accounting
>>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>>> RLIMIT_CPU=0
>>> RLIMIT_FSIZE=0
>>> RLIMIT_DATA=18198528
>>> RLIMIT_STACK=135168
>>> RLIMIT_CORE=0
>>> RLIMIT_RSS=0
>>> RLIMIT_NPROC=1
>>> RLIMIT_NOFILE=55
>>> RLIMIT_MEMLOCK=0
>>> RLIMIT_AS=130879488
>>> RLIMIT_LOCKS=0
>>> RLIMIT_SIGPENDING=0
>>> RLIMIT_MSGQUEUE=0
>>> RLIMIT_NICE=0
>>> RLIMIT_RTPRIO=0
>>> RLIMIT_RTTIME=0
>>
>> Does this mean that rlimit_data and rlimit_stack should be set to the
>> values as specified by the data above?
>
> My plan is that either system administrator, distro maintainer or even
> upstream developer can get reasonable values for the limits. They may
> still be wrong, but things would be better than without any help to
> configure the system.
This is not necessarily true. It seems like there is a disconnect
between what these various values are for and what you are positioning
them as. Most of these limits are meant to protect the system from
resource starvation crashes. They aren't meant to be any sort of double
check on a specific application. The vast majority of applications can
have bugs, leak resources, and do all sorts of other bad things and
still not hit these limits. A program that leaks a file handle an hour
but only normally has 50 handles in use would take 950 hours of constant
leaking before these limits would kick in to bring the program under
control. That's over a month. What's more though, the kernel couldn't
really care less that a single application leaked files until it got to
1000 open. The real point of the limit on file handles (since they are
cheap) is just not to let the system get brought down. Someone could
maliciously fire up 1000 processes, and they could all attempt to open
up as many files as possible in order to drown the system in open
inodes. The combination of the limit on maximum user processes and
maximum files per process are intended to prevent this. They are not
intended to prevent a single, properly running application from
operating. In fact, there are very few applications that are likely to
break the 1000 file per process limit. It is outrageously high for most
applications. They will leak files and do all sorts of bad things
without this ever stopping them. But it does stop malicious programs.
And the process limit stops malicious users too. The max locked memory
is used by almost no processes, and for the very few that use it, the
default is more than enough. The major exception is the RDMA stack,
which uses it so much that we just disable it on large systems because
it's impossible to predict how much we'll need and we don't want a job
to get killed because it couldn't get the memory it needs for buffers.
The limit on POSIX message queues is another one where it's more than
enough for most applications which don't use this feature at all, and
the few systems that use this feature adjust the limit to something sane
on their system (we can't make the default sane for these special
systems or else it becomes an avenue for Denial of Service attack, so
the default must stay low and servers that make extensive use of this
feature must up their limit on a case by case basis).
>>
>> Do we expect a smart user space daemon to then tweak the RLIMIT values?
>
> Someone could write an autotuning daemon that checks if the system has
> changed (for example due to upgrade) and then run some tests to
> reconfigure the system. But the limits are a bit too fragile, or rather,
> applications can't handle failure, so I don't know if that would really
> work.
This misses the point of most of these limits. They aren't there to
keep normal processes and normal users in check. They are there to stop
runaway use. This runaway situation might be accidental, or it might be
a nefarious users. They are generally set exceedingly high for those
things every application uses, and fairly low for those things that
almost no application uses but which could be abused by the nefarious
user crowd.
Moreover, for a large percentage of applications, the highwatermark is a
source of great trickery. For instance, if you have a web server that
is hosting web pages written in python, and therefore are using
mod_python in the httpd server (assuming apache here), then your
highwatermark will never be a reliable, stable thing. If you get 1000
web requests in a minute, all utilizing the mod_python resource in the
web server, and you don't have your httpd configured to restart after
every few hundred requests handled, then mod_python in your httpd
process will grow seemingly without limit. It will consume tons of
memory. And the only limit on how much memory it will consume is
determined by how many web requests it handles in between its garbage
collection intervals * how much memory it allocates per request. If you
don't happen to catch the absolute highest amount while you are
gathering your watermarks, then when you actually switch the system to
enforcing the limits you learned from all your highwatermarks (you are
planning on doing that aren't you?....I didn't see a copy of the patch
1/14, so I don't know if this infrastructure ever goes back to enforcing
the limits or not, but I would assume so, what point is there in
learning what the limits should be if you then never turn around and
enforce them?), load spikes will cause random program failures.
Really, this looks like a solution in search of a problem. Right now,
the limits are set where they are because they do two things:
1) Stay out of the way of the vast majority of applications. Those
applications that get tripped up by the defaults (like RDMA applications
getting stopped by memlock settings) have setup guides that spell out
which limits need changed and hints on what to change them too.
2) Stop nefarious users or errant applications from a total runaway
situation on a machine.
If your applications run without fail unless they have already failed,
and the whole machine doesn't go down with your failed application, then
the limits are working as designed. If your typical machine
configuration includes 256GB of RAM, then you could probably stand to
increase some of the limits safely if you wanted to. But unless you
have applications getting killed because of these limits, why would you?
Right now, I'm inclined to NAK the patch set. I've only seen patch 9/14
since you didn't Cc: everyone on the patch 1/14 that added the
infrastructure. But, as I mentioned in another email, I think this can
be accomplished via a systemtap script instead so we keep the clutter
out of the kernel. And more importantly, these patches seem to be
thinking about these limits as though they are supposed to be some sort
of tight fitting container around applications that catch an errant
application as soon as it steps out of bounds. Nothing could be further
from the truth, and if we actually implemented something of that sort,
programs susceptible to high resource usage during load spikes would
suddenly start failing on a frequent basis. The proof that these limits
are working is given by the fact that we rarely hear from users about
their programs being killed for resource consumption, and yet we also
don't hear from users about their systems going down due to runaway
applications. From what I can tell from these patches, I would suspect
complaints from one of those two issues to increase once these patches
are in place and put in use, and that doesn't seem like a good thing.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-18 22:05 ` Doug Ledford
0 siblings, 0 replies; 95+ messages in thread
From: Doug Ledford @ 2016-07-18 22:05 UTC (permalink / raw)
To: Topi Miettinen, bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit,
Alex Williamson, Alexander Viro, Tejun Heo, Li Zefan,
Johannes Weiner, Peter Zijlstra, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Markus Elfring,
David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
[-- Attachment #1.1: Type: text/plain, Size: 8959 bytes --]
On 7/15/2016 12:35 PM, Topi Miettinen wrote:
> On 07/15/16 13:04, Balbir Singh wrote:
>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>> Hello,
>>>
>>> There are many basic ways to control processes, including capabilities,
>>> cgroups and resource limits. However, there are far fewer ways to find out
>>> useful values for the limits, except blind trial and error.
>>>
>>> This patch series attempts to fix that by giving at least a nice starting
>>> point from the highwater mark values of the resources in question.
>>> I looked where each limit is checked and added a call to update the mark
>>> nearby.
>>>
>>> Example run of program from Documentation/accounting/getdelauys.c:
>>>
>>> ./getdelays -R -p `pidof smartd`
>>> printing resource accounting
>>> RLIMIT_CPU=0
>>> RLIMIT_FSIZE=0
>>> RLIMIT_DATA=18198528
>>> RLIMIT_STACK=135168
>>> RLIMIT_CORE=0
>>> RLIMIT_RSS=0
>>> RLIMIT_NPROC=1
>>> RLIMIT_NOFILE=55
>>> RLIMIT_MEMLOCK=0
>>> RLIMIT_AS=130879488
>>> RLIMIT_LOCKS=0
>>> RLIMIT_SIGPENDING=0
>>> RLIMIT_MSGQUEUE=0
>>> RLIMIT_NICE=0
>>> RLIMIT_RTPRIO=0
>>> RLIMIT_RTTIME=0
>>>
>>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>>> printing resource accounting
>>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>>> RLIMIT_CPU=0
>>> RLIMIT_FSIZE=0
>>> RLIMIT_DATA=18198528
>>> RLIMIT_STACK=135168
>>> RLIMIT_CORE=0
>>> RLIMIT_RSS=0
>>> RLIMIT_NPROC=1
>>> RLIMIT_NOFILE=55
>>> RLIMIT_MEMLOCK=0
>>> RLIMIT_AS=130879488
>>> RLIMIT_LOCKS=0
>>> RLIMIT_SIGPENDING=0
>>> RLIMIT_MSGQUEUE=0
>>> RLIMIT_NICE=0
>>> RLIMIT_RTPRIO=0
>>> RLIMIT_RTTIME=0
>>
>> Does this mean that rlimit_data and rlimit_stack should be set to the
>> values as specified by the data above?
>
> My plan is that either system administrator, distro maintainer or even
> upstream developer can get reasonable values for the limits. They may
> still be wrong, but things would be better than without any help to
> configure the system.
This is not necessarily true. It seems like there is a disconnect
between what these various values are for and what you are positioning
them as. Most of these limits are meant to protect the system from
resource starvation crashes. They aren't meant to be any sort of double
check on a specific application. The vast majority of applications can
have bugs, leak resources, and do all sorts of other bad things and
still not hit these limits. A program that leaks a file handle an hour
but only normally has 50 handles in use would take 950 hours of constant
leaking before these limits would kick in to bring the program under
control. That's over a month. What's more though, the kernel couldn't
really care less that a single application leaked files until it got to
1000 open. The real point of the limit on file handles (since they are
cheap) is just not to let the system get brought down. Someone could
maliciously fire up 1000 processes, and they could all attempt to open
up as many files as possible in order to drown the system in open
inodes. The combination of the limit on maximum user processes and
maximum files per process are intended to prevent this. They are not
intended to prevent a single, properly running application from
operating. In fact, there are very few applications that are likely to
break the 1000 file per process limit. It is outrageously high for most
applications. They will leak files and do all sorts of bad things
without this ever stopping them. But it does stop malicious programs.
And the process limit stops malicious users too. The max locked memory
is used by almost no processes, and for the very few that use it, the
default is more than enough. The major exception is the RDMA stack,
which uses it so much that we just disable it on large systems because
it's impossible to predict how much we'll need and we don't want a job
to get killed because it couldn't get the memory it needs for buffers.
The limit on POSIX message queues is another one where it's more than
enough for most applications which don't use this feature at all, and
the few systems that use this feature adjust the limit to something sane
on their system (we can't make the default sane for these special
systems or else it becomes an avenue for Denial of Service attack, so
the default must stay low and servers that make extensive use of this
feature must up their limit on a case by case basis).
>>
>> Do we expect a smart user space daemon to then tweak the RLIMIT values?
>
> Someone could write an autotuning daemon that checks if the system has
> changed (for example due to upgrade) and then run some tests to
> reconfigure the system. But the limits are a bit too fragile, or rather,
> applications can't handle failure, so I don't know if that would really
> work.
This misses the point of most of these limits. They aren't there to
keep normal processes and normal users in check. They are there to stop
runaway use. This runaway situation might be accidental, or it might be
a nefarious users. They are generally set exceedingly high for those
things every application uses, and fairly low for those things that
almost no application uses but which could be abused by the nefarious
user crowd.
Moreover, for a large percentage of applications, the highwatermark is a
source of great trickery. For instance, if you have a web server that
is hosting web pages written in python, and therefore are using
mod_python in the httpd server (assuming apache here), then your
highwatermark will never be a reliable, stable thing. If you get 1000
web requests in a minute, all utilizing the mod_python resource in the
web server, and you don't have your httpd configured to restart after
every few hundred requests handled, then mod_python in your httpd
process will grow seemingly without limit. It will consume tons of
memory. And the only limit on how much memory it will consume is
determined by how many web requests it handles in between its garbage
collection intervals * how much memory it allocates per request. If you
don't happen to catch the absolute highest amount while you are
gathering your watermarks, then when you actually switch the system to
enforcing the limits you learned from all your highwatermarks (you are
planning on doing that aren't you?....I didn't see a copy of the patch
1/14, so I don't know if this infrastructure ever goes back to enforcing
the limits or not, but I would assume so, what point is there in
learning what the limits should be if you then never turn around and
enforce them?), load spikes will cause random program failures.
Really, this looks like a solution in search of a problem. Right now,
the limits are set where they are because they do two things:
1) Stay out of the way of the vast majority of applications. Those
applications that get tripped up by the defaults (like RDMA applications
getting stopped by memlock settings) have setup guides that spell out
which limits need changed and hints on what to change them too.
2) Stop nefarious users or errant applications from a total runaway
situation on a machine.
If your applications run without fail unless they have already failed,
and the whole machine doesn't go down with your failed application, then
the limits are working as designed. If your typical machine
configuration includes 256GB of RAM, then you could probably stand to
increase some of the limits safely if you wanted to. But unless you
have applications getting killed because of these limits, why would you?
Right now, I'm inclined to NAK the patch set. I've only seen patch 9/14
since you didn't Cc: everyone on the patch 1/14 that added the
infrastructure. But, as I mentioned in another email, I think this can
be accomplished via a systemtap script instead so we keep the clutter
out of the kernel. And more importantly, these patches seem to be
thinking about these limits as though they are supposed to be some sort
of tight fitting container around applications that catch an errant
application as soon as it steps out of bounds. Nothing could be further
from the truth, and if we actually implemented something of that sort,
programs susceptible to high resource usage during load spikes would
suddenly start failing on a frequent basis. The proof that these limits
are working is given by the fact that we rarely hear from users about
their programs being killed for resource consumption, and yet we also
don't hear from users about their systems going down due to runaway
applications. From what I can tell from these patches, I would suspect
complaints from one of those two issues to increase once these patches
are in place and put in use, and that doesn't seem like a good thing.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-18 22:05 ` Doug Ledford
(?)
@ 2016-07-19 16:53 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-19 16:53 UTC (permalink / raw)
To: Doug Ledford, bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit
On 07/18/16 22:05, Doug Ledford wrote:
> On 7/15/2016 12:35 PM, Topi Miettinen wrote:
>> On 07/15/16 13:04, Balbir Singh wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>>
>>>> Example run of program from Documentation/accounting/getdelauys.c:
>>>>
>>>> ./getdelays -R -p `pidof smartd`
>>>> printing resource accounting
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>>
>>>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>>>> printing resource accounting
>>>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>
>>> Does this mean that rlimit_data and rlimit_stack should be set to the
>>> values as specified by the data above?
>>
>> My plan is that either system administrator, distro maintainer or even
>> upstream developer can get reasonable values for the limits. They may
>> still be wrong, but things would be better than without any help to
>> configure the system.
>
> This is not necessarily true. It seems like there is a disconnect
> between what these various values are for and what you are positioning
> them as. Most of these limits are meant to protect the system from
> resource starvation crashes. They aren't meant to be any sort of double
> check on a specific application. The vast majority of applications can
> have bugs, leak resources, and do all sorts of other bad things and
> still not hit these limits. A program that leaks a file handle an hour
> but only normally has 50 handles in use would take 950 hours of constant
> leaking before these limits would kick in to bring the program under
> control. That's over a month. What's more though, the kernel couldn't
> really care less that a single application leaked files until it got to
> 1000 open. The real point of the limit on file handles (since they are
> cheap) is just not to let the system get brought down. Someone could
> maliciously fire up 1000 processes, and they could all attempt to open
> up as many files as possible in order to drown the system in open
> inodes. The combination of the limit on maximum user processes and
> maximum files per process are intended to prevent this. They are not
> intended to prevent a single, properly running application from
> operating. In fact, there are very few applications that are likely to
> break the 1000 file per process limit. It is outrageously high for most
> applications. They will leak files and do all sorts of bad things
> without this ever stopping them. But it does stop malicious programs.
> And the process limit stops malicious users too. The max locked memory
> is used by almost no processes, and for the very few that use it, the
> default is more than enough. The major exception is the RDMA stack,
> which uses it so much that we just disable it on large systems because
> it's impossible to predict how much we'll need and we don't want a job
> to get killed because it couldn't get the memory it needs for buffers.
> The limit on POSIX message queues is another one where it's more than
> enough for most applications which don't use this feature at all, and
> the few systems that use this feature adjust the limit to something sane
> on their system (we can't make the default sane for these special
> systems or else it becomes an avenue for Denial of Service attack, so
> the default must stay low and servers that make extensive use of this
> feature must up their limit on a case by case basis).
>
>>>
>>> Do we expect a smart user space daemon to then tweak the RLIMIT values?
>>
>> Someone could write an autotuning daemon that checks if the system has
>> changed (for example due to upgrade) and then run some tests to
>> reconfigure the system. But the limits are a bit too fragile, or rather,
>> applications can't handle failure, so I don't know if that would really
>> work.
>
> This misses the point of most of these limits. They aren't there to
> keep normal processes and normal users in check. They are there to stop
> runaway use. This runaway situation might be accidental, or it might be
> a nefarious users. They are generally set exceedingly high for those
> things every application uses, and fairly low for those things that
> almost no application uses but which could be abused by the nefarious
> user crowd.
>
> Moreover, for a large percentage of applications, the highwatermark is a
> source of great trickery. For instance, if you have a web server that
> is hosting web pages written in python, and therefore are using
> mod_python in the httpd server (assuming apache here), then your
> highwatermark will never be a reliable, stable thing. If you get 1000
> web requests in a minute, all utilizing the mod_python resource in the
> web server, and you don't have your httpd configured to restart after
> every few hundred requests handled, then mod_python in your httpd
> process will grow seemingly without limit. It will consume tons of
> memory. And the only limit on how much memory it will consume is
> determined by how many web requests it handles in between its garbage
> collection intervals * how much memory it allocates per request. If you
> don't happen to catch the absolute highest amount while you are
> gathering your watermarks, then when you actually switch the system to
> enforcing the limits you learned from all your highwatermarks (you are
> planning on doing that aren't you?....I didn't see a copy of the patch
> 1/14, so I don't know if this infrastructure ever goes back to enforcing
> the limits or not, but I would assume so, what point is there in
> learning what the limits should be if you then never turn around and
> enforce them?), load spikes will cause random program failures.
>
> Really, this looks like a solution in search of a problem. Right now,
> the limits are set where they are because they do two things:
>
> 1) Stay out of the way of the vast majority of applications. Those
> applications that get tripped up by the defaults (like RDMA applications
> getting stopped by memlock settings) have setup guides that spell out
> which limits need changed and hints on what to change them too.
>
> 2) Stop nefarious users or errant applications from a total runaway
> situation on a machine.
>
> If your applications run without fail unless they have already failed,
> and the whole machine doesn't go down with your failed application, then
> the limits are working as designed. If your typical machine
> configuration includes 256GB of RAM, then you could probably stand to
> increase some of the limits safely if you wanted to. But unless you
> have applications getting killed because of these limits, why would you?
Thanks for the long explanation. I'd suppose loose limits are also used
because it's hard to know good tighter values. I was thinking of using
tighter settings to make things less easy for exploit writers. With
tight limits for RLIMIT_AS, RLIMIT_DATA and RLIMIT_STACK (also
RLIMIT_FSIZE in case a daemon is not supposed to create new files) it
would not so easy for the initial exploit to mmap() a large next stage
payload.
But there could be more direct ways to prevent that. For example, if
there was a way for seccomp filters to access a share state, they could
implement a state machine that could switch to a stricter mode after the
application has entered the event loop. Most of the limits or the denial
of service case are not interesting to me anyway.
> Right now, I'm inclined to NAK the patch set. I've only seen patch 9/14
> since you didn't Cc: everyone on the patch 1/14 that added the
> infrastructure. But, as I mentioned in another email, I think this can
> be accomplished via a systemtap script instead so we keep the clutter
> out of the kernel. And more importantly, these patches seem to be
> thinking about these limits as though they are supposed to be some sort
> of tight fitting container around applications that catch an errant
> application as soon as it steps out of bounds. Nothing could be further
> from the truth, and if we actually implemented something of that sort,
> programs susceptible to high resource usage during load spikes would
> suddenly start failing on a frequent basis. The proof that these limits
> are working is given by the fact that we rarely hear from users about
> their programs being killed for resource consumption, and yet we also
> don't hear from users about their systems going down due to runaway
> applications. From what I can tell from these patches, I would suspect
> complaints from one of those two issues to increase once these patches
> are in place and put in use, and that doesn't seem like a good thing.
>
Those complaints could increase either way if the users want to use
tight limits, with kernel assistance or with systemtap. Again, the cause
of lack of complaints could also be that users are unaware of how to get
tight limits, so the users have no option but to either ignore the
limits or to use loose settings.
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-19 16:53 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-19 16:53 UTC (permalink / raw)
To: Doug Ledford, bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit,
Alex Williamson, Alexander Viro, Tejun Heo, Li Zefan,
Johannes Weiner, Peter Zijlstra, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Markus Elfring,
David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/18/16 22:05, Doug Ledford wrote:
> On 7/15/2016 12:35 PM, Topi Miettinen wrote:
>> On 07/15/16 13:04, Balbir Singh wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>>
>>>> Example run of program from Documentation/accounting/getdelauys.c:
>>>>
>>>> ./getdelays -R -p `pidof smartd`
>>>> printing resource accounting
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>>
>>>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>>>> printing resource accounting
>>>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>
>>> Does this mean that rlimit_data and rlimit_stack should be set to the
>>> values as specified by the data above?
>>
>> My plan is that either system administrator, distro maintainer or even
>> upstream developer can get reasonable values for the limits. They may
>> still be wrong, but things would be better than without any help to
>> configure the system.
>
> This is not necessarily true. It seems like there is a disconnect
> between what these various values are for and what you are positioning
> them as. Most of these limits are meant to protect the system from
> resource starvation crashes. They aren't meant to be any sort of double
> check on a specific application. The vast majority of applications can
> have bugs, leak resources, and do all sorts of other bad things and
> still not hit these limits. A program that leaks a file handle an hour
> but only normally has 50 handles in use would take 950 hours of constant
> leaking before these limits would kick in to bring the program under
> control. That's over a month. What's more though, the kernel couldn't
> really care less that a single application leaked files until it got to
> 1000 open. The real point of the limit on file handles (since they are
> cheap) is just not to let the system get brought down. Someone could
> maliciously fire up 1000 processes, and they could all attempt to open
> up as many files as possible in order to drown the system in open
> inodes. The combination of the limit on maximum user processes and
> maximum files per process are intended to prevent this. They are not
> intended to prevent a single, properly running application from
> operating. In fact, there are very few applications that are likely to
> break the 1000 file per process limit. It is outrageously high for most
> applications. They will leak files and do all sorts of bad things
> without this ever stopping them. But it does stop malicious programs.
> And the process limit stops malicious users too. The max locked memory
> is used by almost no processes, and for the very few that use it, the
> default is more than enough. The major exception is the RDMA stack,
> which uses it so much that we just disable it on large systems because
> it's impossible to predict how much we'll need and we don't want a job
> to get killed because it couldn't get the memory it needs for buffers.
> The limit on POSIX message queues is another one where it's more than
> enough for most applications which don't use this feature at all, and
> the few systems that use this feature adjust the limit to something sane
> on their system (we can't make the default sane for these special
> systems or else it becomes an avenue for Denial of Service attack, so
> the default must stay low and servers that make extensive use of this
> feature must up their limit on a case by case basis).
>
>>>
>>> Do we expect a smart user space daemon to then tweak the RLIMIT values?
>>
>> Someone could write an autotuning daemon that checks if the system has
>> changed (for example due to upgrade) and then run some tests to
>> reconfigure the system. But the limits are a bit too fragile, or rather,
>> applications can't handle failure, so I don't know if that would really
>> work.
>
> This misses the point of most of these limits. They aren't there to
> keep normal processes and normal users in check. They are there to stop
> runaway use. This runaway situation might be accidental, or it might be
> a nefarious users. They are generally set exceedingly high for those
> things every application uses, and fairly low for those things that
> almost no application uses but which could be abused by the nefarious
> user crowd.
>
> Moreover, for a large percentage of applications, the highwatermark is a
> source of great trickery. For instance, if you have a web server that
> is hosting web pages written in python, and therefore are using
> mod_python in the httpd server (assuming apache here), then your
> highwatermark will never be a reliable, stable thing. If you get 1000
> web requests in a minute, all utilizing the mod_python resource in the
> web server, and you don't have your httpd configured to restart after
> every few hundred requests handled, then mod_python in your httpd
> process will grow seemingly without limit. It will consume tons of
> memory. And the only limit on how much memory it will consume is
> determined by how many web requests it handles in between its garbage
> collection intervals * how much memory it allocates per request. If you
> don't happen to catch the absolute highest amount while you are
> gathering your watermarks, then when you actually switch the system to
> enforcing the limits you learned from all your highwatermarks (you are
> planning on doing that aren't you?....I didn't see a copy of the patch
> 1/14, so I don't know if this infrastructure ever goes back to enforcing
> the limits or not, but I would assume so, what point is there in
> learning what the limits should be if you then never turn around and
> enforce them?), load spikes will cause random program failures.
>
> Really, this looks like a solution in search of a problem. Right now,
> the limits are set where they are because they do two things:
>
> 1) Stay out of the way of the vast majority of applications. Those
> applications that get tripped up by the defaults (like RDMA applications
> getting stopped by memlock settings) have setup guides that spell out
> which limits need changed and hints on what to change them too.
>
> 2) Stop nefarious users or errant applications from a total runaway
> situation on a machine.
>
> If your applications run without fail unless they have already failed,
> and the whole machine doesn't go down with your failed application, then
> the limits are working as designed. If your typical machine
> configuration includes 256GB of RAM, then you could probably stand to
> increase some of the limits safely if you wanted to. But unless you
> have applications getting killed because of these limits, why would you?
Thanks for the long explanation. I'd suppose loose limits are also used
because it's hard to know good tighter values. I was thinking of using
tighter settings to make things less easy for exploit writers. With
tight limits for RLIMIT_AS, RLIMIT_DATA and RLIMIT_STACK (also
RLIMIT_FSIZE in case a daemon is not supposed to create new files) it
would not so easy for the initial exploit to mmap() a large next stage
payload.
But there could be more direct ways to prevent that. For example, if
there was a way for seccomp filters to access a share state, they could
implement a state machine that could switch to a stricter mode after the
application has entered the event loop. Most of the limits or the denial
of service case are not interesting to me anyway.
> Right now, I'm inclined to NAK the patch set. I've only seen patch 9/14
> since you didn't Cc: everyone on the patch 1/14 that added the
> infrastructure. But, as I mentioned in another email, I think this can
> be accomplished via a systemtap script instead so we keep the clutter
> out of the kernel. And more importantly, these patches seem to be
> thinking about these limits as though they are supposed to be some sort
> of tight fitting container around applications that catch an errant
> application as soon as it steps out of bounds. Nothing could be further
> from the truth, and if we actually implemented something of that sort,
> programs susceptible to high resource usage during load spikes would
> suddenly start failing on a frequent basis. The proof that these limits
> are working is given by the fact that we rarely hear from users about
> their programs being killed for resource consumption, and yet we also
> don't hear from users about their systems going down due to runaway
> applications. From what I can tell from these patches, I would suspect
> complaints from one of those two issues to increase once these patches
> are in place and put in use, and that doesn't seem like a good thing.
>
Those complaints could increase either way if the users want to use
tight limits, with kernel assistance or with systemtap. Again, the cause
of lack of complaints could also be that users are unaware of how to get
tight limits, so the users have no option but to either ignore the
limits or to use loose settings.
-Topi
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-19 16:53 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-19 16:53 UTC (permalink / raw)
To: Doug Ledford, bsingharora
Cc: linux-kernel, Jonathan Corbet, Tony Luck, Fenghua Yu,
Alexander Graf, Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit,
Alex Williamson, Alexander Viro, Tejun Heo, Li Zefan,
Johannes Weiner, Peter Zijlstra, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Markus Elfring,
David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Richard Weinberger,
Wang Xiaoqiang, Helge Deller, Mateusz Guzik, Alex Thorlton,
Ben Segall, John Stultz, Rik van Riel, Eric B Munson,
Alexey Klimov, Chen Gang, Andrey Ryabinin, David Rientjes,
Hugh Dickins, Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/18/16 22:05, Doug Ledford wrote:
> On 7/15/2016 12:35 PM, Topi Miettinen wrote:
>> On 07/15/16 13:04, Balbir Singh wrote:
>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>> Hello,
>>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find out
>>>> useful values for the limits, except blind trial and error.
>>>>
>>>> This patch series attempts to fix that by giving at least a nice starting
>>>> point from the highwater mark values of the resources in question.
>>>> I looked where each limit is checked and added a call to update the mark
>>>> nearby.
>>>>
>>>> Example run of program from Documentation/accounting/getdelauys.c:
>>>>
>>>> ./getdelays -R -p `pidof smartd`
>>>> printing resource accounting
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>>
>>>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>>>> printing resource accounting
>>>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>>>> RLIMIT_CPU=0
>>>> RLIMIT_FSIZE=0
>>>> RLIMIT_DATA=18198528
>>>> RLIMIT_STACK=135168
>>>> RLIMIT_CORE=0
>>>> RLIMIT_RSS=0
>>>> RLIMIT_NPROC=1
>>>> RLIMIT_NOFILE=55
>>>> RLIMIT_MEMLOCK=0
>>>> RLIMIT_AS=130879488
>>>> RLIMIT_LOCKS=0
>>>> RLIMIT_SIGPENDING=0
>>>> RLIMIT_MSGQUEUE=0
>>>> RLIMIT_NICE=0
>>>> RLIMIT_RTPRIO=0
>>>> RLIMIT_RTTIME=0
>>>
>>> Does this mean that rlimit_data and rlimit_stack should be set to the
>>> values as specified by the data above?
>>
>> My plan is that either system administrator, distro maintainer or even
>> upstream developer can get reasonable values for the limits. They may
>> still be wrong, but things would be better than without any help to
>> configure the system.
>
> This is not necessarily true. It seems like there is a disconnect
> between what these various values are for and what you are positioning
> them as. Most of these limits are meant to protect the system from
> resource starvation crashes. They aren't meant to be any sort of double
> check on a specific application. The vast majority of applications can
> have bugs, leak resources, and do all sorts of other bad things and
> still not hit these limits. A program that leaks a file handle an hour
> but only normally has 50 handles in use would take 950 hours of constant
> leaking before these limits would kick in to bring the program under
> control. That's over a month. What's more though, the kernel couldn't
> really care less that a single application leaked files until it got to
> 1000 open. The real point of the limit on file handles (since they are
> cheap) is just not to let the system get brought down. Someone could
> maliciously fire up 1000 processes, and they could all attempt to open
> up as many files as possible in order to drown the system in open
> inodes. The combination of the limit on maximum user processes and
> maximum files per process are intended to prevent this. They are not
> intended to prevent a single, properly running application from
> operating. In fact, there are very few applications that are likely to
> break the 1000 file per process limit. It is outrageously high for most
> applications. They will leak files and do all sorts of bad things
> without this ever stopping them. But it does stop malicious programs.
> And the process limit stops malicious users too. The max locked memory
> is used by almost no processes, and for the very few that use it, the
> default is more than enough. The major exception is the RDMA stack,
> which uses it so much that we just disable it on large systems because
> it's impossible to predict how much we'll need and we don't want a job
> to get killed because it couldn't get the memory it needs for buffers.
> The limit on POSIX message queues is another one where it's more than
> enough for most applications which don't use this feature at all, and
> the few systems that use this feature adjust the limit to something sane
> on their system (we can't make the default sane for these special
> systems or else it becomes an avenue for Denial of Service attack, so
> the default must stay low and servers that make extensive use of this
> feature must up their limit on a case by case basis).
>
>>>
>>> Do we expect a smart user space daemon to then tweak the RLIMIT values?
>>
>> Someone could write an autotuning daemon that checks if the system has
>> changed (for example due to upgrade) and then run some tests to
>> reconfigure the system. But the limits are a bit too fragile, or rather,
>> applications can't handle failure, so I don't know if that would really
>> work.
>
> This misses the point of most of these limits. They aren't there to
> keep normal processes and normal users in check. They are there to stop
> runaway use. This runaway situation might be accidental, or it might be
> a nefarious users. They are generally set exceedingly high for those
> things every application uses, and fairly low for those things that
> almost no application uses but which could be abused by the nefarious
> user crowd.
>
> Moreover, for a large percentage of applications, the highwatermark is a
> source of great trickery. For instance, if you have a web server that
> is hosting web pages written in python, and therefore are using
> mod_python in the httpd server (assuming apache here), then your
> highwatermark will never be a reliable, stable thing. If you get 1000
> web requests in a minute, all utilizing the mod_python resource in the
> web server, and you don't have your httpd configured to restart after
> every few hundred requests handled, then mod_python in your httpd
> process will grow seemingly without limit. It will consume tons of
> memory. And the only limit on how much memory it will consume is
> determined by how many web requests it handles in between its garbage
> collection intervals * how much memory it allocates per request. If you
> don't happen to catch the absolute highest amount while you are
> gathering your watermarks, then when you actually switch the system to
> enforcing the limits you learned from all your highwatermarks (you are
> planning on doing that aren't you?....I didn't see a copy of the patch
> 1/14, so I don't know if this infrastructure ever goes back to enforcing
> the limits or not, but I would assume so, what point is there in
> learning what the limits should be if you then never turn around and
> enforce them?), load spikes will cause random program failures.
>
> Really, this looks like a solution in search of a problem. Right now,
> the limits are set where they are because they do two things:
>
> 1) Stay out of the way of the vast majority of applications. Those
> applications that get tripped up by the defaults (like RDMA applications
> getting stopped by memlock settings) have setup guides that spell out
> which limits need changed and hints on what to change them too.
>
> 2) Stop nefarious users or errant applications from a total runaway
> situation on a machine.
>
> If your applications run without fail unless they have already failed,
> and the whole machine doesn't go down with your failed application, then
> the limits are working as designed. If your typical machine
> configuration includes 256GB of RAM, then you could probably stand to
> increase some of the limits safely if you wanted to. But unless you
> have applications getting killed because of these limits, why would you?
Thanks for the long explanation. I'd suppose loose limits are also used
because it's hard to know good tighter values. I was thinking of using
tighter settings to make things less easy for exploit writers. With
tight limits for RLIMIT_AS, RLIMIT_DATA and RLIMIT_STACK (also
RLIMIT_FSIZE in case a daemon is not supposed to create new files) it
would not so easy for the initial exploit to mmap() a large next stage
payload.
But there could be more direct ways to prevent that. For example, if
there was a way for seccomp filters to access a share state, they could
implement a state machine that could switch to a stricter mode after the
application has entered the event loop. Most of the limits or the denial
of service case are not interesting to me anyway.
> Right now, I'm inclined to NAK the patch set. I've only seen patch 9/14
> since you didn't Cc: everyone on the patch 1/14 that added the
> infrastructure. But, as I mentioned in another email, I think this can
> be accomplished via a systemtap script instead so we keep the clutter
> out of the kernel. And more importantly, these patches seem to be
> thinking about these limits as though they are supposed to be some sort
> of tight fitting container around applications that catch an errant
> application as soon as it steps out of bounds. Nothing could be further
> from the truth, and if we actually implemented something of that sort,
> programs susceptible to high resource usage during load spikes would
> suddenly start failing on a frequent basis. The proof that these limits
> are working is given by the fact that we rarely hear from users about
> their programs being killed for resource consumption, and yet we also
> don't hear from users about their systems going down due to runaway
> applications. From what I can tell from these patches, I would suspect
> complaints from one of those two issues to increase once these patches
> are in place and put in use, and that doesn't seem like a good thing.
>
Those complaints could increase either way if the users want to use
tight limits, with kernel assistance or with systemtap. Again, the cause
of lack of complaints could also be that users are unaware of how to get
tight limits, so the users have no option but to either ignore the
limits or to use loose settings.
-Topi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 10:35 ` Topi Miettinen
(?)
@ 2016-07-15 14:19 ` Richard Weinberger
-1 siblings, 0 replies; 95+ messages in thread
From: Richard Weinberger @ 2016-07-15 14:19 UTC (permalink / raw)
To: Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
Hi!
Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> In this example, smartd is running as a non-root user. The presented
> values can be used as a starting point for giving new limits to the
> service.
I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
calls just to get these metrics.
Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
Thanks,
//richard
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 14:19 ` Richard Weinberger
0 siblings, 0 replies; 95+ messages in thread
From: Richard Weinberger @ 2016-07-15 14:19 UTC (permalink / raw)
To: Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Wang Xiaoqiang, Helge Deller,
Mateusz Guzik, Alex Thorlton, Ben Segall, John Stultz,
Rik van Riel, Eric B Munson, Alexey Klimov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
Hi!
Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> In this example, smartd is running as a non-root user. The presented
> values can be used as a starting point for giving new limits to the
> service.
I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
calls just to get these metrics.
Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
Thanks,
//richard
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 14:19 ` Richard Weinberger
0 siblings, 0 replies; 95+ messages in thread
From: Richard Weinberger @ 2016-07-15 14:19 UTC (permalink / raw)
To: Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Wang Xiaoqiang, Helge Deller,
Mateusz Guzik, Alex Thorlton, Ben Segall, John Stultz,
Rik van Riel, Eric B Munson, Alexey Klimov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
Hi!
Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This patch series attempts to fix that by giving at least a nice starting
> point from the highwater mark values of the resources in question.
> I looked where each limit is checked and added a call to update the mark
> nearby.
>
> Example run of program from Documentation/accounting/getdelauys.c:
>
> ./getdelays -R -p `pidof smartd`
> printing resource accounting
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
> printing resource accounting
> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
> RLIMIT_CPU=0
> RLIMIT_FSIZE=0
> RLIMIT_DATA=18198528
> RLIMIT_STACK=135168
> RLIMIT_CORE=0
> RLIMIT_RSS=0
> RLIMIT_NPROC=1
> RLIMIT_NOFILE=55
> RLIMIT_MEMLOCK=0
> RLIMIT_AS=130879488
> RLIMIT_LOCKS=0
> RLIMIT_SIGPENDING=0
> RLIMIT_MSGQUEUE=0
> RLIMIT_NICE=0
> RLIMIT_RTPRIO=0
> RLIMIT_RTTIME=0
>
> In this example, smartd is running as a non-root user. The presented
> values can be used as a starting point for giving new limits to the
> service.
I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
calls just to get these metrics.
Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
Thanks,
//richard
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 14:19 ` Richard Weinberger
(?)
@ 2016-07-15 17:19 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:19 UTC (permalink / raw)
To: Richard Weinberger, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
On 07/15/16 14:19, Richard Weinberger wrote:
> Hi!
>
> Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> In this example, smartd is running as a non-root user. The presented
>> values can be used as a starting point for giving new limits to the
>> service.
>
> I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
> calls just to get these metrics.
>
> Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
I don't know. What kind of changes do you think would be needed?
-Topi
>
> Thanks,
> //richard
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 17:19 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:19 UTC (permalink / raw)
To: Richard Weinberger, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Wang Xiaoqiang, Helge Deller,
Mateusz Guzik, Alex Thorlton, Ben Segall, John Stultz,
Rik van Riel, Eric B Munson, Alexey Klimov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 14:19, Richard Weinberger wrote:
> Hi!
>
> Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> In this example, smartd is running as a non-root user. The presented
>> values can be used as a starting point for giving new limits to the
>> service.
>
> I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
> calls just to get these metrics.
>
> Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
I don't know. What kind of changes do you think would be needed?
-Topi
>
> Thanks,
> //richard
>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-15 17:19 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:19 UTC (permalink / raw)
To: Richard Weinberger, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Wang Xiaoqiang, Helge Deller,
Mateusz Guzik, Alex Thorlton, Ben Segall, John Stultz,
Rik van Riel, Eric B Munson, Alexey Klimov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
On 07/15/16 14:19, Richard Weinberger wrote:
> Hi!
>
> Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> In this example, smartd is running as a non-root user. The presented
>> values can be used as a starting point for giving new limits to the
>> service.
>
> I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
> calls just to get these metrics.
>
> Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
I don't know. What kind of changes do you think would be needed?
-Topi
>
> Thanks,
> //richard
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 95+ messages in thread
* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 14:19 ` Richard Weinberger
@ 2016-07-18 21:25 ` Doug Ledford
-1 siblings, 0 replies; 95+ messages in thread
From: Doug Ledford @ 2016-07-18 21:25 UTC (permalink / raw)
To: Richard Weinberger, Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell
[-- Attachment #1.1: Type: text/plain, Size: 2270 bytes --]
On 7/15/2016 10:19 AM, Richard Weinberger wrote:
> Hi!
>
> Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> In this example, smartd is running as a non-root user. The presented
>> values can be used as a starting point for giving new limits to the
>> service.
>
> I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
> calls just to get these metrics.
>
> Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
I'm not sure about perf (I don't know the internals of perf well enough
to comment), but I'm sure the systemtap infrastructure could do this,
and a preconfigured systemtap script could be shipped with the package
that would allow this.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-07-18 21:25 ` Doug Ledford
0 siblings, 0 replies; 95+ messages in thread
From: Doug Ledford @ 2016-07-18 21:25 UTC (permalink / raw)
To: Richard Weinberger, Topi Miettinen, linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Sean Hefty, Hal Rosenstock, Mike Marciniszyn, Dennis Dalessandro,
Christian Benvenuti, Dave Goodell, Sudeep Dutt, Ashutosh Dixit,
Alex Williamson, Alexander Viro, Tejun Heo, Li Zefan,
Johannes Weiner, Peter Zijlstra, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Alexander Shishkin, Balbir Singh,
Markus Elfring, David S. Miller, Nicolas Dichtel, Andrew Morton,
Konstantin Khlebnikov, Jiri Slaby, Cyrill Gorcunov, Michal Hocko,
Vlastimil Babka, Dave Hansen, Greg Kroah-Hartman, Dan Carpenter,
Michael Kerrisk, Kirill A. Shutemov, Marcus Gelderie,
Vladimir Davydov, Joe Perches, Frederic Weisbecker,
Andrea Arcangeli, Eric W. Biederman, Andi Kleen, Oleg Nesterov,
Stas Sergeev, Amanieu d'Antras, Wang Xiaoqiang, Helge Deller,
Mateusz Guzik, Alex Thorlton, Ben Segall, John Stultz,
Rik van Riel, Eric B Munson, Alexey Klimov, Chen Gang,
Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
[-- Attachment #1.1: Type: text/plain, Size: 2270 bytes --]
On 7/15/2016 10:19 AM, Richard Weinberger wrote:
> Hi!
>
> Am 15.07.2016 um 12:35 schrieb Topi Miettinen:
>> Hello,
>>
>> There are many basic ways to control processes, including capabilities,
>> cgroups and resource limits. However, there are far fewer ways to find out
>> useful values for the limits, except blind trial and error.
>>
>> This patch series attempts to fix that by giving at least a nice starting
>> point from the highwater mark values of the resources in question.
>> I looked where each limit is checked and added a call to update the mark
>> nearby.
>>
>> Example run of program from Documentation/accounting/getdelauys.c:
>>
>> ./getdelays -R -p `pidof smartd`
>> printing resource accounting
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> ./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
>> printing resource accounting
>> sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
>> RLIMIT_CPU=0
>> RLIMIT_FSIZE=0
>> RLIMIT_DATA=18198528
>> RLIMIT_STACK=135168
>> RLIMIT_CORE=0
>> RLIMIT_RSS=0
>> RLIMIT_NPROC=1
>> RLIMIT_NOFILE=55
>> RLIMIT_MEMLOCK=0
>> RLIMIT_AS=130879488
>> RLIMIT_LOCKS=0
>> RLIMIT_SIGPENDING=0
>> RLIMIT_MSGQUEUE=0
>> RLIMIT_NICE=0
>> RLIMIT_RTPRIO=0
>> RLIMIT_RTTIME=0
>>
>> In this example, smartd is running as a non-root user. The presented
>> values can be used as a starting point for giving new limits to the
>> service.
>
> I don't think it is worth sprinkling the kernel with update_resource_highwatermark()
> calls just to get these metrics.
>
> Can't we teach the existing perf infrastructure to collect these highwatermarks for us?
I'm not sure about perf (I don't know the internals of perf well enough
to comment), but I'm sure the systemtap infrastructure could do this,
and a preconfigured systemtap script could be shipped with the package
that would allow this.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 95+ messages in thread
* [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 10:35 ` Topi Miettinen
` (20 preceding siblings ...)
(?)
@ 2016-07-15 17:42 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-07-15 17:42 UTC (permalink / raw)
To: linux-kernel
(Resending just to lkml due to message header limits)
Hello,
There are many basic ways to control processes, including capabilities,
cgroups and resource limits. However, there are far fewer ways to find out
useful values for the limits, except blind trial and error.
This patch series attempts to fix that by giving at least a nice starting
point from the highwater mark values of the resources in question.
I looked where each limit is checked and added a call to update the mark
nearby.
Example run of program from Documentation/accounting/getdelauys.c:
./getdelays -R -p `pidof smartd`
printing resource accounting
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
./getdelays -R -C /sys/fs/cgroup/systemd/system.slice/smartd.service/
printing resource accounting
sleeping 1, blocked 0, running 0, stopped 0, uninterruptible 0
RLIMIT_CPU=0
RLIMIT_FSIZE=0
RLIMIT_DATA=18198528
RLIMIT_STACK=135168
RLIMIT_CORE=0
RLIMIT_RSS=0
RLIMIT_NPROC=1
RLIMIT_NOFILE=55
RLIMIT_MEMLOCK=0
RLIMIT_AS=130879488
RLIMIT_LOCKS=0
RLIMIT_SIGPENDING=0
RLIMIT_MSGQUEUE=0
RLIMIT_NICE=0
RLIMIT_RTPRIO=0
RLIMIT_RTTIME=0
In this example, smartd is running as a non-root user. The presented
values can be used as a starting point for giving new limits to the
service.
There's one problem with the patch 07/13, kernel initialization calls
create_worker() which seems to use different locking model or something:
[ 0.145410] =========================================================
[ 0.148000] [ INFO: possible irq lock inversion dependency detected ]
[ 0.148000] 4.7.0-rc7+ #155 Not tainted
[ 0.148000] ---------------------------------------------------------
[ 0.148000] swapper/0/1 just changed the state of lock:
[ 0.148000] (&(&(&sig->stats_lock)->lock)->rlock){+.....}, at:
[<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] but this lock was taken by another, HARDIRQ-safe lock in
the past:
[ 0.148000] (&rq->lock){-.....}
and interrupts could create inverse lock ordering between them.
[ 0.148000] [ 0.148000] other info that might help us debug this:
[ 0.148000] Possible interrupt unsafe locking scenario:
[ 0.148000] [ 0.148000] CPU0 CPU1
[ 0.148000] ---- ----
[ 0.148000] lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] local_irq_disable();
[ 0.148000] lock(&rq->lock);
[ 0.148000]
lock(&(&(&sig->stats_lock)->lock)->rlock);
[ 0.148000] <Interrupt>
[ 0.148000] lock(&rq->lock);
[ 0.148000] [ 0.148000] *** DEADLOCK ***
[ 0.148000] [ 0.148000] 2 locks held by swapper/0/1:
[ 0.148000] #0: (cpu_hotplug.lock){.+.+.+}, at:
[<ffffffff81092824>] get_online_cpus+0x24/0x70
[ 0.148000] #1: (smpboot_threads_lock){+.+.+.}, at:
[<ffffffff810ba517>] smpboot_register_percpu_thread_cpumask+0x37/0xf0
[ 0.148000] [ 0.148000] the shortest dependencies between 2nd lock
and 1st lock:
[ 0.148000] -> (&rq->lock){-.....} ops: 181 {
[ 0.148000] IN-HARDIRQ-W at:
[ 0.148000] [<ffffffff810e8439>]
__lock_acquire+0x6e9/0x1440
[ 0.148000] [<ffffffff810e95d3>]
lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>]
_raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c3a41>]
scheduler_tick+0x41/0xd0
[ 0.148000] [<ffffffff81110471>]
update_process_times+0x51/0x60
[ 0.148000] [<ffffffff8111fa4f>]
tick_periodic+0x2f/0xc0
[ 0.148000] [<ffffffff8111fb05>]
tick_handle_periodic+0x25/0x70
[ 0.148000] [<ffffffff8101ebf5>]
timer_interrupt+0x15/0x20
[ 0.148000] [<ffffffff810fc731>]
handle_irq_event_percpu+0x41/0x320
[ 0.148000] [<ffffffff810fca49>]
handle_irq_event+0x39/0x60
[ 0.148000] [<ffffffff810ffe08>]
handle_level_irq+0x88/0x110
[ 0.148000] [<ffffffff8101e58a>]
handle_irq+0x1a/0x30
[ 0.148000] [<ffffffff818d2281>] do_IRQ+0x61/0x120
[ 0.148000] [<ffffffff818d0949>]
ret_from_intr+0x0/0x19
[ 0.148000] [<ffffffff810fe969>]
__setup_irq+0x3f9/0x5e0
[ 0.148000] [<ffffffff810feb96>]
setup_irq+0x46/0xa0
[ 0.148000] [<ffffffff821878e2>]
setup_default_timer_irq+0x1e/0x20
[ 0.148000] [<ffffffff821878fb>]
hpet_time_init+0x17/0x19
[ 0.148000] [<ffffffff821878bd>]
x86_late_time_init+0xa/0x11
[ 0.148000] [<ffffffff82181ef9>]
start_kernel+0x39d/0x465
[ 0.148000] [<ffffffff82181294>]
x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>]
x86_64_start_kernel+0x178/0x18b
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>]
__lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>]
lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf82c>]
_raw_spin_lock_irqsave+0x3c/0x50
[ 0.148000] [<ffffffff810bdc9d>]
rq_attach_root+0x1d/0x100
[ 0.148000] [<ffffffff8219deab>]
sched_init+0x2f5/0x44c
[ 0.148000] [<ffffffff82181d9d>]
start_kernel+0x241/0x465
[ 0.148000] [<ffffffff82181294>]
x86_64_start_reservations+0x2f/0x31
[ 0.148000] [<ffffffff8218140e>]
x86_64_start_kernel+0x178/0x18b
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f3ad0>] __key.60059+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>] set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>] set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>] create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>] init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [ 0.148000] ->
(&(&(&sig->stats_lock)->lock)->rlock){+.....} ops: 2 {
[ 0.148000] HARDIRQ-ON-W at:
[ 0.148000] [<ffffffff810e82e0>]
__lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>]
lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>]
_raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>]
__sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>]
_sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>]
sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>]
cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>]
__smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>]
smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>]
cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>]
do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>]
kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>]
kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>]
ret_from_fork+0x1f/0x40
[ 0.148000] INITIAL USE at:
[ 0.148000] [<ffffffff810e7f90>]
__lock_acquire+0x240/0x1440
[ 0.148000] [<ffffffff810e95d3>]
lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>]
_raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810c0514>]
set_user_nice.part.92+0xf4/0x270
[ 0.148000] [<ffffffff810c06b6>]
set_user_nice+0x26/0x30
[ 0.148000] [<ffffffff810aee10>]
create_worker+0xf0/0x1a0
[ 0.148000] [<ffffffff8219c195>]
init_workqueues+0x317/0x51e
[ 0.148000] [<ffffffff81000450>]
do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>]
kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>]
ret_from_fork+0x1f/0x40
[ 0.148000] }
[ 0.148000] ... key at: [<ffffffff822f2190>] __key.55894+0x0/0x8
[ 0.148000] ... acquired at:
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>]
__smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>]
smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [ 0.148000] [ 0.148000] stack backtrace:
[ 0.148000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc7+ #155
[ 0.148000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Debian-1.8.2-1 04/01/2014
[ 0.148000] 0000000000000086 00000000aea03eae ffff88003de6ba60
ffffffff813cb2d5
[ 0.148000] ffffffff82d48e60 ffff88003de6bac0 ffff88003de6baa0
ffffffff811a6b05
[ 0.148000] ffff88003de647d8 ffff88003de647d8 ffff88003de64040
ffffffff81d531a7
[ 0.148000] Call Trace:
[ 0.148000] [<ffffffff813cb2d5>] dump_stack+0x67/0x92
[ 0.148000] [<ffffffff811a6b05>]
print_irq_inversion_bug.part.38+0x1a4/0x1b0
[ 0.148000] [<ffffffff810e6885>] check_usage_backwards+0x155/0x160
[ 0.148000] [<ffffffff810e7533>] mark_lock+0x333/0x610
[ 0.148000] [<ffffffff810e6730>] ? check_usage_forwards+0x160/0x160
[ 0.148000] [<ffffffff810e82e0>] __lock_acquire+0x590/0x1440
[ 0.148000] [<ffffffff810e7a6d>] ? trace_hardirqs_on+0xd/0x10
[ 0.148000] [<ffffffff81104aad>] ? debug_lockdep_rcu_enabled+0x1d/0x20
[ 0.148000] [<ffffffff810e95d3>] lock_acquire+0xe3/0x1c0
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff818cf661>] _raw_spin_lock+0x31/0x40
[ 0.148000] [<ffffffff810bf769>] ? __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810bf769>] __sched_setscheduler+0x339/0xbd0
[ 0.148000] [<ffffffff810c0076>] _sched_setscheduler+0x76/0x90
[ 0.148000] [<ffffffff810c1012>] sched_set_stop_task+0x62/0xb0
[ 0.148000] [<ffffffff81143983>] cpu_stop_create+0x23/0x30
[ 0.148000] [<ffffffff810ba48d>]
__smpboot_create_thread.part.2+0xad/0x100
[ 0.148000] [<ffffffff810ba57f>]
smpboot_register_percpu_thread_cpumask+0x9f/0xf0
[ 0.148000] [<ffffffff821a1708>] cpu_stop_init+0x7d/0xb8
[ 0.148000] [<ffffffff821a168b>] ? pid_namespaces_init+0x40/0x40
[ 0.148000] [<ffffffff81000450>] do_one_initcall+0x50/0x180
[ 0.148000] [<ffffffff8102c24d>] ? print_cpu_info+0x7d/0xe0
[ 0.148000] [<ffffffff821820d2>] kernel_init_freeable+0x111/0x25d
[ 0.148000] [<ffffffff818c206e>] kernel_init+0xe/0x100
[ 0.148000] [<ffffffff818d01ff>] ret_from_fork+0x1f/0x40
[ 0.148000] [<ffffffff818c2060>] ? rest_init+0x130/0x130
In this v2, I tried to address all comments, thanks for reviews.
-Topi
Topi Miettinen (14):
resource limits: foundation for resource highwater tracking
resource limits: aggregate task highwater marks to cgroup level
resource limits: track highwater mark of file sizes
resource limits: track highwater mark of VM data segment
resource limits: track highwater mark of stack size
resource limits: track highwater mark of cores dumped
resource limits: track highwater mark of user processes
resource limits: track highwater mark of number of files
resource limits: track highwater mark of locked memory
resource limits: track highwater mark of address space size
resource limits: track highwater mark of number of pending signals
resource limits: track highwater mark of size of message queues
resource limits: track highwater mark of niceness
resource limits: track highwater mark of RT priority
Documentation/accounting/getdelays.c | 62 ++++++++++++++++++++++--
arch/ia64/kernel/perfmon.c | 1 +
arch/powerpc/kvm/book3s_64_vio.c | 2 +
arch/powerpc/mm/mmu_context_iommu.c | 2 +
arch/x86/ia32/ia32_aout.c | 2 +
drivers/infiniband/core/umem.c | 1 +
drivers/infiniband/hw/hfi1/user_pages.c | 2 +
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +
drivers/misc/mic/scif/scif_rma.c | 1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +
drivers/vfio/vfio_iommu_type1.c | 5 ++
fs/attr.c | 2 +
fs/binfmt_aout.c | 2 +
fs/binfmt_flat.c | 2 +
fs/coredump.c | 11 +++--
fs/file.c | 4 ++
include/linux/cgroup-defs.h | 5 ++
include/linux/sched.h | 61 +++++++++++++++++++++++
include/linux/tsacct_kern.h | 3 ++
include/uapi/linux/cgroupstats.h | 3 ++
include/uapi/linux/taskstats.h | 10 +++-
ipc/mqueue.c | 1 +
kernel/bpf/syscall.c | 8 +++
kernel/cgroup.c | 78
++++++++++++++++++++++++++++++
kernel/cred.c | 1 +
kernel/events/core.c | 1 +
kernel/fork.c | 2 +
kernel/sched/core.c | 6 +++
kernel/signal.c | 2 +
kernel/sys.c | 5 ++
kernel/taskstats.c | 4 ++
kernel/tsacct.c | 47 ++++++++++++++++++
mm/mlock.c | 8 +++
mm/mmap.c | 17 ++++++-
mm/mremap.c | 7 +++
36 files changed, 365 insertions(+), 9 deletions(-)
--
2.8.1
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
2016-07-15 10:35 ` Topi Miettinen
@ 2016-08-03 18:20 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-08-03 18:20 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit
[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]
Hello,
I'm trying the systemtap approach and it looks promising. The script is
annotating strace-like output with capability, device access and RLIMIT
information. In the end there's a summary. Here's sample output from
wpa_supplicant run:
mprotect(0x7efebf140000, 16384, PROT_READ) = 0 [DATA 548864 -> 573440]
[AS 44986368 -> 45002752]
brk(0x55d9611f8000) = 94392125718528 missing
[Capabilities=CAP_SYS_ADMIN] [AS 45002752 -> 45010944]
open(0x55d960716462, O_RDWR) = 3 [DeviceAllow=/dev/char/1:3 rw ]
open("/dev/random", O_RDONLY|O_NONBLOCK) = 3 [DeviceAllow=/dev/char/1:8 r ]
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
[RestrictAddressFamilies=AF_UNIX] [NOFILE 3 -> 4]
open("/etc/wpa_supplicant.conf", O_RDONLY) = 5 [NOFILE 4 -> 5]
socket(PF_NETLINK, SOCK_RAW, 0) = 5 [RestrictAddressFamilies=AF_NETLINK]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 6
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 5 -> 6]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 7
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 6 -> 7]
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
[RestrictAddressFamilies=AF_INET] [NOFILE 7 -> 8]
open("/dev/rfkill", O_RDONLY) = 9 [DeviceAllow=/dev/char/10:58 r ]
[NOFILE 8 -> 9]
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 10
[RestrictAddressFamilies=AF_UNIX] [NOFILE 9 -> 10]
sendmsg(6, 0x7ffc778f35b0, 0x0) = 36 [Capabilities=CAP_NET_ADMIN]
Summary:
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
Consider also missing CapabilityBoundingSet=CAP_SYS_ADMIN
DeviceAllow=/dev/char/1:3 rw
DeviceAllow=/dev/char/1:8 r
DeviceAllow=/dev/char/10:58 r
DeviceAllow=/dev/char/1:9 r
LimitFSIZE=0
LimitDATA=577536
LimitSTACK=139264
LimitCORE=0
LimitNOFILE=15
LimitAS=45146112
LimitNPROC=171
LimitMEMLOCK=0
LimitSIGPENDING=0
LimitMSGQUEUE=0
LimitNICE=0
LimitRTPRIO=0
RestrictAddressFamilies=AF_UNIX AF_INET AF_NETLINK AF_PACKET
MemoryDenyWriteExecute=true
Some values are not correct. NPROC is wrong because staprun needs to be
run as root instead of the separate privileged user for wpa_supplicant
and that messes user process count. DATA/AS/STACK seems to be a bit off.
I can easily use this as systemd service configuration drop-in otherwise.
Now, the relevant part for the kernel is that I'd like to analyze error
paths better, so the system calls would be also annotated when there's a
failure when a RLIMIT is too tight. It would be easier to insert probes
if there was only one path for RLIMIT checks. Would it be OK to make the
function task_rlimit() a full check against the limit and also make it a
non-inlined function, just for improved probing purposes?
There's already error analysis for the capabilities, but there are some
false positive hits (like brk() complaining about missing CAP_SYS_ADMIN
above).
-Topi
[-- Attachment #2: strace.stp --]
[-- Type: text/plain, Size: 19078 bytes --]
#! /bin/sh
# suppress some run-time errors here for cleaner output
//bin/true && exec stap --suppress-handler-errors --skip-badvars $0 ${1+"$@"}
/*
* Compile:
* stap -p4 -DSTP_NO_OVERLOAD -m strace
* Run:
* /usr/bin/staprun -R -c "/sbin/wpa_supplicant -u -O /run/wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0" -w /root/strace.ko only_capability_use=1 timestamp=0
*/
/* configuration options; set these with stap -G */
global follow_fork = 0 /* -Gfollow_fork=1 means trace descendant processes too */
global timestamp = 1 /* -Gtimestamp=0 means don't print a syscall timestamp */
global elapsed_time = 0 /* -Gelapsed_time=1 means print a syscall duration too */
global only_capability_use = 0 /* -Gonly_capability_use=1 means print only when capabilities are used */
global thread_argstr%
global thread_time%
global syscalls_nonreturn[2]
global capnames[64]
global used_caps
global missing_caps
global all_used_caps
global all_missing_caps
global accessed_devices[1000]
global all_accessed_devices[1000]
global highwatermark_fsize
global highwatermark_data
global highwatermark_stack
global highwatermark_core
global highwatermark_nproc
global highwatermark_nofile
global highwatermark_memlock
global highwatermark_as
global highwatermark_sigpending
global highwatermark_msgqueue
global highwatermark_nice
global highwatermark_rtprio
global old_highwatermark_fsize
global old_highwatermark_data
global old_highwatermark_stack
global old_highwatermark_core
global old_highwatermark_nproc
global old_highwatermark_nofile
global old_highwatermark_memlock
global old_highwatermark_as
global old_highwatermark_sigpending
global old_highwatermark_msgqueue
global old_highwatermark_nice
global old_highwatermark_rtprio
global afnames[64]
global used_afs
global missing_afs
global all_used_afs
global all_missing_afs
global no_memory_deny_write_execute
global all_memory_deny_write_execute = "true"
global print_syscall
probe begin
{
/* list those syscalls that never .return */
syscalls_nonreturn["exit"]=1
syscalls_nonreturn["exit_group"]=1
// grep '#define CAP_.*[0-9]+$' /usr/src/linux-headers*/include/uapi/linux/capability.h | awk '{ print "capnames[" $3 "] = \"" $2 "\";" }'
capnames[0] = "CAP_CHOWN";
capnames[1] = "CAP_DAC_OVERRIDE";
capnames[2] = "CAP_DAC_READ_SEARCH";
capnames[3] = "CAP_FOWNER";
capnames[4] = "CAP_FSETID";
capnames[5] = "CAP_KILL";
capnames[6] = "CAP_SETGID";
capnames[7] = "CAP_SETUID";
capnames[8] = "CAP_SETPCAP";
capnames[9] = "CAP_LINUX_IMMUTABLE";
capnames[10] = "CAP_NET_BIND_SERVICE";
capnames[11] = "CAP_NET_BROADCAST";
capnames[12] = "CAP_NET_ADMIN";
capnames[13] = "CAP_NET_RAW";
capnames[14] = "CAP_IPC_LOCK";
capnames[15] = "CAP_IPC_OWNER";
capnames[16] = "CAP_SYS_MODULE";
capnames[17] = "CAP_SYS_RAWIO";
capnames[18] = "CAP_SYS_CHROOT";
capnames[19] = "CAP_SYS_PTRACE";
capnames[20] = "CAP_SYS_PACCT";
capnames[21] = "CAP_SYS_ADMIN";
capnames[22] = "CAP_SYS_BOOT";
capnames[23] = "CAP_SYS_NICE";
capnames[24] = "CAP_SYS_RESOURCE";
capnames[25] = "CAP_SYS_TIME";
capnames[26] = "CAP_SYS_TTY_CONFIG";
capnames[27] = "CAP_MKNOD";
capnames[28] = "CAP_LEASE";
capnames[29] = "CAP_AUDIT_WRITE";
capnames[30] = "CAP_AUDIT_CONTROL";
capnames[31] = "CAP_SETFCAP";
capnames[32] = "CAP_MAC_OVERRIDE";
capnames[33] = "CAP_MAC_ADMIN";
capnames[34] = "CAP_SYSLOG";
capnames[35] = "CAP_WAKE_ALARM";
capnames[36] = "CAP_BLOCK_SUSPEND";
capnames[37] = "CAP_AUDIT_READ";
//grep '#define AF_.*' /usr/src/linux-headers-*/include/linux/socket.h | awk '{ print "afnames[" $3 "] = \"" $2 "\"" }'
afnames[0] = "AF_UNSPEC"
afnames[1] = "AF_UNIX"
afnames[2] = "AF_INET"
afnames[3] = "AF_AX25"
afnames[4] = "AF_IPX"
afnames[5] = "AF_APPLETALK"
afnames[6] = "AF_NETROM"
afnames[7] = "AF_BRIDGE"
afnames[8] = "AF_ATMPVC"
afnames[9] = "AF_X25"
afnames[10] = "AF_INET6"
afnames[11] = "AF_ROSE"
afnames[12] = "AF_DECnet"
afnames[13] = "AF_NETBEUI"
afnames[14] = "AF_SECURITY"
afnames[15] = "AF_KEY"
afnames[16] = "AF_NETLINK"
afnames[17] = "AF_PACKET"
afnames[18] = "AF_ASH"
afnames[19] = "AF_ECONET"
afnames[20] = "AF_ATMSVC"
afnames[21] = "AF_RDS"
afnames[22] = "AF_SNA"
afnames[23] = "AF_IRDA"
afnames[24] = "AF_PPPOX"
afnames[25] = "AF_WANPIPE"
afnames[26] = "AF_LLC"
afnames[27] = "AF_IB"
afnames[28] = "AF_MPLS"
afnames[29] = "AF_CAN"
afnames[30] = "AF_TIPC"
afnames[31] = "AF_BLUETOOTH"
afnames[32] = "AF_IUCV"
afnames[33] = "AF_RXRPC"
afnames[34] = "AF_ISDN"
afnames[35] = "AF_PHONET"
afnames[36] = "AF_IEEE802154"
afnames[37] = "AF_CAIF"
afnames[38] = "AF_ALG"
afnames[39] = "AF_NFC"
afnames[40] = "AF_VSOCK"
afnames[41] = "AF_KCM"
}
function filter_p()
{
if (target() == 0) return 0; /* system-wide */
if (!follow_fork && pid() != target()) return 1; /* single-process */
if (follow_fork && !target_set_pid(pid())) return 1; /* multi-process */
return 0;
}
function caps_to_str(caps)
{
str = ""
for (i = 0; i < 37; i++) # CAP_LAST_CAP
if (caps & (1 << i)) {
str .= capnames[i]
if ((caps & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
function dev_to_str(type, dev, access)
{
devs = "/dev/"
if (type == 1) # DEV_BLOCK
devs .= "block"
else
devs .= "char"
devs .= sprintf("/%d:%d ", dev >> 32, dev & 0xffffffff)
if (access & 2) # ACC_READ
devs .= "r"
if (access & 4) # ACC_WRITE
devs .= "w"
if (access & 1) # ACC_MKNOD
devs .= "m"
return devs
}
function afs_to_str(afs)
{
str = ""
for (i = 0; i < 42; i++) # MAX_AF
if (afs & (1 << i)) {
str .= afnames[i]
if ((afs & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
/* Capabilities */
probe kernel.function("cap_capable@security/commoncap.c").return
{
if (filter_p()) next;
if ($return == 0 && $audit)
used_caps |= 1 << $cap;
else
missing_caps |= 1 << $cap;
}
/* Devices */
probe kernel.function("__devcgroup_check_permission@security/device_cgroup.c").return
{
if (filter_p()) next;
if ($return == 0)
accessed_devices[$type, $major << 32 | $minor] |= $access
}
/* RLIMIT_FSIZE */
probe kernel.function("inode_newsize_ok@fs/attr.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_fsize < $offset)
highwatermark_fsize = $offset
}
/* RLIMIT_DATA */
probe kernel.function("prctl_set_mm@kernel/sys.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_data < $prctl_map->end_data - $prctl_map->start_data) {
highwatermark_data = $prctl_map->end_data - $prctl_map->start_data
print_syscall = 1
}
}
probe kernel.function("do_brk@mm/mmap.c").return
{
if (filter_p()) next;
task = task_current()
if ($return > 0 && highwatermark_data < task->mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = task->mm->data_vm << 12
print_syscall = 1
}
if ($return > 0 && highwatermark_as < task->mm->total_vm << 12) {
highwatermark_as = task->mm->total_vm << 12
print_syscall = 1
}
}
/* also RLIMIT_STACK and RLIMIT_MEMLOCK */
probe kernel.function("vm_stat_account@mm/mmap.c").return
{
if (filter_p()) next;
if (highwatermark_data < $mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = $mm->data_vm << 12
print_syscall = 1
}
if (highwatermark_stack < $mm->stack_vm << 12) {
highwatermark_stack = $mm->stack_vm << 12
print_syscall = 1
}
if (highwatermark_memlock < atomic_long_read(&$mm->locked_vm) << 12) {
highwatermark_memlock = atomic_long_read(&$mm->locked_vm) << 12
print_syscall = 1
}
if (highwatermark_as < $mm->total_vm << 12) {
highwatermark_as = $mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_CORE */
probe kernel.function("dump_emit@fs/coredump.c").return
{
if (filter_p()) next;
if (highwatermark_core < $cprm->written) {
highwatermark_core = $cprm->written
print_syscall = 1
}
}
/* RLIMIT_NPROC */
probe kernel.function("commit_creds@kernel/cred.c").return
{
if (filter_p()) next;
if (highwatermark_nproc < atomic_read(&$new->user->processes)) {
highwatermark_nproc = atomic_read(&$new->user->processes)
print_syscall = 1
}
}
probe kernel.function("copy_process@kernel/fork.c").return
{
if (filter_p()) next;
printf("return %d\n", $return);
try {
if (($return > 0 || $return < -1000) && $return->real_cred && $return->real_cred->user)
printf("good return %d\n", $return);
if (highwatermark_nproc < atomic_read(&$return->real_cred->user->processes)) {
highwatermark_nproc = atomic_read(&$return->real_cred->user->processes)
print_syscall = 1
}
} catch {}
}
/* RLIMIT_NOFILE */
probe kernel.function("__alloc_fd@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
probe kernel.function("do_dup2@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
/* RLIMIT_MEMLOCK */
probe kernel.function("sys_bpf@kernel/bpf/syscall.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_memlock < atomic_long_read(&user->locked_vm) << 12) { # PAGE_SHIFT
highwatermark_memlock = atomic_long_read(&user->locked_vm) << 12
print_syscall = 1
}
}
probe kernel.function("perf_mmap@kernel/events/core.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->pinned_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->pinned_vm << 12
print_syscall = 1
}
}
probe kernel.function("do_mlock@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->locked_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->locked_vm << 12
print_syscall = 1
}
}
probe kernel.function("sys_mlockall@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->total_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_SIGPENDING */
probe kernel.function("__sigqueue_alloc@kernel/signal.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_sigpending < atomic_read(&user->sigpending)) {
highwatermark_sigpending = atomic_read(&user->sigpending)
print_syscall = 1
}
}
/* RLIMIT_MSGGQUEUE */
probe kernel.function("mqueue_get_inode@ipc/mqueue.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_msgqueue < user->mq_bytes) {
highwatermark_msgqueue = user->mq_bytes
print_syscall = 1
}
}
/* RLIMIT_NICE */
probe kernel.function("set_user_nice@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_nice < $nice) {
highwatermark_nice = $nice
print_syscall = 1
}
}
/* RLIMIT_RTPRIO */
probe kernel.function("__sched_setscheduler@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_rtprio < $attr->sched_priority) {
highwatermark_rtprio = $attr->sched_priority
print_syscall = 1
}
}
/* socket address families */
probe kernel.function("__sock_create@net/socket.c").return
{
if (filter_p()) next;
if ($return == 0) {
used_afs |= 1 << $family
print_syscall = 1
} else if ($return == 93) { # EPROTONOSUPPORT
missing_afs |= 1 << $family
print_syscall = 1
}
}
/* mmap flags */
probe kernel.function("do_mmap@mm/mmap.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && ($flags & (2 | 4)) == (2 | 4)) { # PROT_WRITE | PROT_EXEC
no_memory_deny_write_execute = 1
print_syscall = 1
}
}
/* system call printing */
probe nd_syscall.*
{
# TODO: filter out apparently-nested syscalls (that are implemented
# in terms of each other within the kernel); PR6762
if (filter_p()) next;
thread_argstr[tid()]=argstr
if (timestamp || elapsed_time)
thread_time[tid()]=gettimeofday_us()
if (name in syscalls_nonreturn)
report(name,argstr,"")
}
probe nd_syscall.*.return
{
if (filter_p()) next;
report(name,thread_argstr[tid()],retstr)
}
function report(syscall_name, syscall_argstr, syscall_retstr)
{
if (timestamp || elapsed_time)
{
now = gettimeofday_us()
then = thread_time[tid()]
if (timestamp)
prefix=sprintf("%s.%06d ", ctime(then/1000000), then%1000000)
if (elapsed_time && (now>then)) {
diff = now-then
suffix=sprintf(" <%d.%06d>", diff/1000000, diff%1000000)
}
delete thread_time[tid()]
}
/* add a thread-id string in lots of cases, except if
stap strace.stp -c SINGLE_THREADED_CMD */
if (tid() != target()) {
prefix .= sprintf("%s[%d] ", execname(), tid())
}
if (used_caps) {
suffix .= " [Capabilities=" . caps_to_str(used_caps) . "]"
all_used_caps |= used_caps
print_syscall = 1
}
if (missing_caps) {
suffix .= " missing [Capabilities=" . caps_to_str(missing_caps) . "]"
all_missing_caps |= missing_caps
print_syscall = 1
}
foreach ([type, dev] in accessed_devices) {
devs .= dev_to_str(type, dev, accessed_devices[type, dev]) . " "
if (has_devs == 0) {
has_devs = 1
print_syscall = 1
devs = " [DeviceAllow=" . devs
}
all_accessed_devices[type, dev] = accessed_devices[type, dev];
}
if (has_devs) {
devs .= "]"
suffix .= devs
}
if (used_afs) {
suffix .= " [RestrictAddressFamilies=" . afs_to_str(used_afs) . "]"
all_used_afs |= used_afs
print_syscall = 1
}
if (missing_afs) {
suffix .= " missing [RestrictAddressFamilies=" . afs_to_str(missing_afs) . "]"
all_missing_afs |= missing_afs
print_syscall = 1
}
if (no_memory_deny_write_execute) {
suffix .= " [MemoryDenyWriteExecute=false]"
all_memory_deny_write_execute = "false"
}
if (highwatermark_fsize > old_highwatermark_fsize) {
suffix .= sprintf(" [FSIZE %d -> %d]", old_highwatermark_fsize, highwatermark_fsize)
old_highwatermark_fsize = highwatermark_fsize
}
if (highwatermark_data > old_highwatermark_data) {
suffix .= sprintf(" [DATA %d -> %d]", old_highwatermark_data, highwatermark_data)
old_highwatermark_data = highwatermark_data
}
if (highwatermark_stack > old_highwatermark_stack) {
suffix .= sprintf(" [STACK %d -> %d]", old_highwatermark_stack, highwatermark_stack)
old_highwatermark_stack = highwatermark_stack
}
if (highwatermark_core > old_highwatermark_core) {
suffix .= sprintf(" [CORE %d -> %d]", old_highwatermark_core, highwatermark_core)
old_highwatermark_core = highwatermark_core
}
if (highwatermark_nofile > old_highwatermark_nofile) {
suffix .= sprintf(" [NOFILE %d -> %d]", old_highwatermark_nofile, highwatermark_nofile)
old_highwatermark_nofile = highwatermark_nofile
}
if (highwatermark_as > old_highwatermark_as) {
suffix .= sprintf(" [AS %d -> %d]", old_highwatermark_as, highwatermark_as)
old_highwatermark_as = highwatermark_as
}
if (highwatermark_nproc > old_highwatermark_nproc) {
suffix .= sprintf(" [NPROC %d -> %d]", old_highwatermark_nproc, highwatermark_nproc)
old_highwatermark_nproc = highwatermark_nproc
}
if (highwatermark_memlock > old_highwatermark_memlock) {
suffix .= sprintf(" [MEMLOCK %d -> %d]", old_highwatermark_memlock, highwatermark_memlock)
old_highwatermark_memlock = highwatermark_memlock
}
if (highwatermark_sigpending > old_highwatermark_sigpending) {
suffix .= sprintf(" [SIGPENDING %d -> %d]", old_highwatermark_sigpending, highwatermark_sigpending)
old_highwatermark_sigpending = highwatermark_sigpending
}
if (highwatermark_msgqueue > old_highwatermark_msgqueue) {
suffix .= sprintf(" [MSGQUEUE %d -> %d]", old_highwatermark_msgqueue, highwatermark_msgqueue)
old_highwatermark_msgqueue = highwatermark_msgqueue
}
if (highwatermark_nice > old_highwatermark_nice) {
suffix .= sprintf(" [NICE %d -> %d]", old_highwatermark_nice, highwatermark_nice)
old_highwatermark_nice = highwatermark_nice
}
if (highwatermark_rtprio > old_highwatermark_rtprio) {
suffix .= sprintf(" [RTPRIO %d -> %d]", old_highwatermark_rtprio, highwatermark_rtprio)
old_highwatermark_rtprio = highwatermark_rtprio
}
if (!only_capability_use || print_syscall)
printf("%s%s(%s) = %s%s\n",
prefix,
syscall_name, syscall_argstr, syscall_retstr,
suffix)
used_caps = 0
missing_caps = 0
used_afs = 0
print_syscall = 0
no_memory_deny_write_execute = 0
delete accessed_devices
delete thread_argstr[tid()]
}
probe end
{
printf("\nSummary:\n")
printf("CapabilityBoundingSet=%s\n", caps_to_str(all_used_caps))
if (all_missing_caps)
printf("Consider also missing CapabilityBoundingSet=%s\n", caps_to_str(all_missing_caps))
foreach ([type, dev] in all_accessed_devices)
printf("DeviceAllow=%s\n", dev_to_str(type, dev, all_accessed_devices[type, dev]))
printf("LimitFSIZE=%d\n", highwatermark_fsize)
printf("LimitDATA=%d\n", highwatermark_data)
printf("LimitSTACK=%d\n", highwatermark_stack)
printf("LimitCORE=%d\n", highwatermark_core)
printf("LimitNOFILE=%d\n", highwatermark_nofile)
printf("LimitAS=%d\n", highwatermark_as)
printf("LimitNPROC=%d\n", highwatermark_nproc)
printf("LimitMEMLOCK=%d\n", highwatermark_memlock)
printf("LimitSIGPENDING=%d\n", highwatermark_sigpending)
printf("LimitMSGQUEUE=%d\n", highwatermark_msgqueue)
printf("LimitNICE=%d\n", highwatermark_nice)
printf("LimitRTPRIO=%d\n", highwatermark_rtprio)
printf("RestrictAddressFamilies=%s\n", afs_to_str(all_used_afs))
if (all_missing_afs)
printf("Consider also missing RestrictAddressFamilies=%s\n", afs_to_str(all_missing_afs))
printf("MemoryDenyWriteExecute=%s\n", all_memory_deny_write_execute)
}
^ permalink raw reply [flat|nested] 95+ messages in thread* Re: [PATCH 00/14] Present useful limits to user (v2)
@ 2016-08-03 18:20 ` Topi Miettinen
0 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-08-03 18:20 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Corbet, Tony Luck, Fenghua Yu, Alexander Graf,
Paolo Bonzini, Radim Krčmář,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Doug Ledford, Sean Hefty, Hal Rosenstock, Mike Marciniszyn,
Dennis Dalessandro, Christian Benvenuti, Dave Goodell,
Sudeep Dutt, Ashutosh Dixit, Alex Williamson, Alexander Viro,
Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra,
Alexei Starovoitov, Arnaldo Carvalho de Melo, Alexander Shishkin,
Balbir Singh, Markus Elfring, David S. Miller, Nicolas Dichtel,
Andrew Morton, Konstantin Khlebnikov, Jiri Slaby,
Cyrill Gorcunov, Michal Hocko, Vlastimil Babka, Dave Hansen,
Greg Kroah-Hartman, Dan Carpenter, Michael Kerrisk,
Kirill A. Shutemov, Marcus Gelderie, Vladimir Davydov,
Joe Perches, Frederic Weisbecker, Andrea Arcangeli,
Eric W. Biederman, Andi Kleen, Oleg Nesterov, Stas Sergeev,
Amanieu d'Antras, Richard Weinberger, Wang Xiaoqiang,
Helge Deller, Mateusz Guzik, Alex Thorlton, Ben Segall,
John Stultz, Rik van Riel, Eric B Munson, Alexey Klimov,
Chen Gang, Andrey Ryabinin, David Rientjes, Hugh Dickins,
Alexander Kuleshov, open list:DOCUMENTATION,
open list:IA64 (Itanium) PLATFORM,
open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC,
open list:KERNEL VIRTUAL MACHINE (KVM),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:INFINIBAND SUBSYSTEM,
open list:FILESYSTEMS (VFS and infrastructure),
open list:CONTROL GROUP (CGROUP),
open list:BPF (Safe dynamic programs and tools),
open list:MEMORY MANAGEMENT
[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]
Hello,
I'm trying the systemtap approach and it looks promising. The script is
annotating strace-like output with capability, device access and RLIMIT
information. In the end there's a summary. Here's sample output from
wpa_supplicant run:
mprotect(0x7efebf140000, 16384, PROT_READ) = 0 [DATA 548864 -> 573440]
[AS 44986368 -> 45002752]
brk(0x55d9611f8000) = 94392125718528 missing
[Capabilities=CAP_SYS_ADMIN] [AS 45002752 -> 45010944]
open(0x55d960716462, O_RDWR) = 3 [DeviceAllow=/dev/char/1:3 rw ]
open("/dev/random", O_RDONLY|O_NONBLOCK) = 3 [DeviceAllow=/dev/char/1:8 r ]
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
[RestrictAddressFamilies=AF_UNIX] [NOFILE 3 -> 4]
open("/etc/wpa_supplicant.conf", O_RDONLY) = 5 [NOFILE 4 -> 5]
socket(PF_NETLINK, SOCK_RAW, 0) = 5 [RestrictAddressFamilies=AF_NETLINK]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 6
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 5 -> 6]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 7
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 6 -> 7]
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
[RestrictAddressFamilies=AF_INET] [NOFILE 7 -> 8]
open("/dev/rfkill", O_RDONLY) = 9 [DeviceAllow=/dev/char/10:58 r ]
[NOFILE 8 -> 9]
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 10
[RestrictAddressFamilies=AF_UNIX] [NOFILE 9 -> 10]
sendmsg(6, 0x7ffc778f35b0, 0x0) = 36 [Capabilities=CAP_NET_ADMIN]
Summary:
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
Consider also missing CapabilityBoundingSet=CAP_SYS_ADMIN
DeviceAllow=/dev/char/1:3 rw
DeviceAllow=/dev/char/1:8 r
DeviceAllow=/dev/char/10:58 r
DeviceAllow=/dev/char/1:9 r
LimitFSIZE=0
LimitDATA=577536
LimitSTACK=139264
LimitCORE=0
LimitNOFILE=15
LimitAS=45146112
LimitNPROC=171
LimitMEMLOCK=0
LimitSIGPENDING=0
LimitMSGQUEUE=0
LimitNICE=0
LimitRTPRIO=0
RestrictAddressFamilies=AF_UNIX AF_INET AF_NETLINK AF_PACKET
MemoryDenyWriteExecute=true
Some values are not correct. NPROC is wrong because staprun needs to be
run as root instead of the separate privileged user for wpa_supplicant
and that messes user process count. DATA/AS/STACK seems to be a bit off.
I can easily use this as systemd service configuration drop-in otherwise.
Now, the relevant part for the kernel is that I'd like to analyze error
paths better, so the system calls would be also annotated when there's a
failure when a RLIMIT is too tight. It would be easier to insert probes
if there was only one path for RLIMIT checks. Would it be OK to make the
function task_rlimit() a full check against the limit and also make it a
non-inlined function, just for improved probing purposes?
There's already error analysis for the capabilities, but there are some
false positive hits (like brk() complaining about missing CAP_SYS_ADMIN
above).
-Topi
[-- Attachment #2: strace.stp --]
[-- Type: text/plain, Size: 19078 bytes --]
#! /bin/sh
# suppress some run-time errors here for cleaner output
//bin/true && exec stap --suppress-handler-errors --skip-badvars $0 ${1+"$@"}
/*
* Compile:
* stap -p4 -DSTP_NO_OVERLOAD -m strace
* Run:
* /usr/bin/staprun -R -c "/sbin/wpa_supplicant -u -O /run/wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0" -w /root/strace.ko only_capability_use=1 timestamp=0
*/
/* configuration options; set these with stap -G */
global follow_fork = 0 /* -Gfollow_fork=1 means trace descendant processes too */
global timestamp = 1 /* -Gtimestamp=0 means don't print a syscall timestamp */
global elapsed_time = 0 /* -Gelapsed_time=1 means print a syscall duration too */
global only_capability_use = 0 /* -Gonly_capability_use=1 means print only when capabilities are used */
global thread_argstr%
global thread_time%
global syscalls_nonreturn[2]
global capnames[64]
global used_caps
global missing_caps
global all_used_caps
global all_missing_caps
global accessed_devices[1000]
global all_accessed_devices[1000]
global highwatermark_fsize
global highwatermark_data
global highwatermark_stack
global highwatermark_core
global highwatermark_nproc
global highwatermark_nofile
global highwatermark_memlock
global highwatermark_as
global highwatermark_sigpending
global highwatermark_msgqueue
global highwatermark_nice
global highwatermark_rtprio
global old_highwatermark_fsize
global old_highwatermark_data
global old_highwatermark_stack
global old_highwatermark_core
global old_highwatermark_nproc
global old_highwatermark_nofile
global old_highwatermark_memlock
global old_highwatermark_as
global old_highwatermark_sigpending
global old_highwatermark_msgqueue
global old_highwatermark_nice
global old_highwatermark_rtprio
global afnames[64]
global used_afs
global missing_afs
global all_used_afs
global all_missing_afs
global no_memory_deny_write_execute
global all_memory_deny_write_execute = "true"
global print_syscall
probe begin
{
/* list those syscalls that never .return */
syscalls_nonreturn["exit"]=1
syscalls_nonreturn["exit_group"]=1
// grep '#define CAP_.*[0-9]+$' /usr/src/linux-headers*/include/uapi/linux/capability.h | awk '{ print "capnames[" $3 "] = \"" $2 "\";" }'
capnames[0] = "CAP_CHOWN";
capnames[1] = "CAP_DAC_OVERRIDE";
capnames[2] = "CAP_DAC_READ_SEARCH";
capnames[3] = "CAP_FOWNER";
capnames[4] = "CAP_FSETID";
capnames[5] = "CAP_KILL";
capnames[6] = "CAP_SETGID";
capnames[7] = "CAP_SETUID";
capnames[8] = "CAP_SETPCAP";
capnames[9] = "CAP_LINUX_IMMUTABLE";
capnames[10] = "CAP_NET_BIND_SERVICE";
capnames[11] = "CAP_NET_BROADCAST";
capnames[12] = "CAP_NET_ADMIN";
capnames[13] = "CAP_NET_RAW";
capnames[14] = "CAP_IPC_LOCK";
capnames[15] = "CAP_IPC_OWNER";
capnames[16] = "CAP_SYS_MODULE";
capnames[17] = "CAP_SYS_RAWIO";
capnames[18] = "CAP_SYS_CHROOT";
capnames[19] = "CAP_SYS_PTRACE";
capnames[20] = "CAP_SYS_PACCT";
capnames[21] = "CAP_SYS_ADMIN";
capnames[22] = "CAP_SYS_BOOT";
capnames[23] = "CAP_SYS_NICE";
capnames[24] = "CAP_SYS_RESOURCE";
capnames[25] = "CAP_SYS_TIME";
capnames[26] = "CAP_SYS_TTY_CONFIG";
capnames[27] = "CAP_MKNOD";
capnames[28] = "CAP_LEASE";
capnames[29] = "CAP_AUDIT_WRITE";
capnames[30] = "CAP_AUDIT_CONTROL";
capnames[31] = "CAP_SETFCAP";
capnames[32] = "CAP_MAC_OVERRIDE";
capnames[33] = "CAP_MAC_ADMIN";
capnames[34] = "CAP_SYSLOG";
capnames[35] = "CAP_WAKE_ALARM";
capnames[36] = "CAP_BLOCK_SUSPEND";
capnames[37] = "CAP_AUDIT_READ";
//grep '#define AF_.*' /usr/src/linux-headers-*/include/linux/socket.h | awk '{ print "afnames[" $3 "] = \"" $2 "\"" }'
afnames[0] = "AF_UNSPEC"
afnames[1] = "AF_UNIX"
afnames[2] = "AF_INET"
afnames[3] = "AF_AX25"
afnames[4] = "AF_IPX"
afnames[5] = "AF_APPLETALK"
afnames[6] = "AF_NETROM"
afnames[7] = "AF_BRIDGE"
afnames[8] = "AF_ATMPVC"
afnames[9] = "AF_X25"
afnames[10] = "AF_INET6"
afnames[11] = "AF_ROSE"
afnames[12] = "AF_DECnet"
afnames[13] = "AF_NETBEUI"
afnames[14] = "AF_SECURITY"
afnames[15] = "AF_KEY"
afnames[16] = "AF_NETLINK"
afnames[17] = "AF_PACKET"
afnames[18] = "AF_ASH"
afnames[19] = "AF_ECONET"
afnames[20] = "AF_ATMSVC"
afnames[21] = "AF_RDS"
afnames[22] = "AF_SNA"
afnames[23] = "AF_IRDA"
afnames[24] = "AF_PPPOX"
afnames[25] = "AF_WANPIPE"
afnames[26] = "AF_LLC"
afnames[27] = "AF_IB"
afnames[28] = "AF_MPLS"
afnames[29] = "AF_CAN"
afnames[30] = "AF_TIPC"
afnames[31] = "AF_BLUETOOTH"
afnames[32] = "AF_IUCV"
afnames[33] = "AF_RXRPC"
afnames[34] = "AF_ISDN"
afnames[35] = "AF_PHONET"
afnames[36] = "AF_IEEE802154"
afnames[37] = "AF_CAIF"
afnames[38] = "AF_ALG"
afnames[39] = "AF_NFC"
afnames[40] = "AF_VSOCK"
afnames[41] = "AF_KCM"
}
function filter_p()
{
if (target() == 0) return 0; /* system-wide */
if (!follow_fork && pid() != target()) return 1; /* single-process */
if (follow_fork && !target_set_pid(pid())) return 1; /* multi-process */
return 0;
}
function caps_to_str(caps)
{
str = ""
for (i = 0; i < 37; i++) # CAP_LAST_CAP
if (caps & (1 << i)) {
str .= capnames[i]
if ((caps & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
function dev_to_str(type, dev, access)
{
devs = "/dev/"
if (type == 1) # DEV_BLOCK
devs .= "block"
else
devs .= "char"
devs .= sprintf("/%d:%d ", dev >> 32, dev & 0xffffffff)
if (access & 2) # ACC_READ
devs .= "r"
if (access & 4) # ACC_WRITE
devs .= "w"
if (access & 1) # ACC_MKNOD
devs .= "m"
return devs
}
function afs_to_str(afs)
{
str = ""
for (i = 0; i < 42; i++) # MAX_AF
if (afs & (1 << i)) {
str .= afnames[i]
if ((afs & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
/* Capabilities */
probe kernel.function("cap_capable@security/commoncap.c").return
{
if (filter_p()) next;
if ($return == 0 && $audit)
used_caps |= 1 << $cap;
else
missing_caps |= 1 << $cap;
}
/* Devices */
probe kernel.function("__devcgroup_check_permission@security/device_cgroup.c").return
{
if (filter_p()) next;
if ($return == 0)
accessed_devices[$type, $major << 32 | $minor] |= $access
}
/* RLIMIT_FSIZE */
probe kernel.function("inode_newsize_ok@fs/attr.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_fsize < $offset)
highwatermark_fsize = $offset
}
/* RLIMIT_DATA */
probe kernel.function("prctl_set_mm@kernel/sys.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_data < $prctl_map->end_data - $prctl_map->start_data) {
highwatermark_data = $prctl_map->end_data - $prctl_map->start_data
print_syscall = 1
}
}
probe kernel.function("do_brk@mm/mmap.c").return
{
if (filter_p()) next;
task = task_current()
if ($return > 0 && highwatermark_data < task->mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = task->mm->data_vm << 12
print_syscall = 1
}
if ($return > 0 && highwatermark_as < task->mm->total_vm << 12) {
highwatermark_as = task->mm->total_vm << 12
print_syscall = 1
}
}
/* also RLIMIT_STACK and RLIMIT_MEMLOCK */
probe kernel.function("vm_stat_account@mm/mmap.c").return
{
if (filter_p()) next;
if (highwatermark_data < $mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = $mm->data_vm << 12
print_syscall = 1
}
if (highwatermark_stack < $mm->stack_vm << 12) {
highwatermark_stack = $mm->stack_vm << 12
print_syscall = 1
}
if (highwatermark_memlock < atomic_long_read(&$mm->locked_vm) << 12) {
highwatermark_memlock = atomic_long_read(&$mm->locked_vm) << 12
print_syscall = 1
}
if (highwatermark_as < $mm->total_vm << 12) {
highwatermark_as = $mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_CORE */
probe kernel.function("dump_emit@fs/coredump.c").return
{
if (filter_p()) next;
if (highwatermark_core < $cprm->written) {
highwatermark_core = $cprm->written
print_syscall = 1
}
}
/* RLIMIT_NPROC */
probe kernel.function("commit_creds@kernel/cred.c").return
{
if (filter_p()) next;
if (highwatermark_nproc < atomic_read(&$new->user->processes)) {
highwatermark_nproc = atomic_read(&$new->user->processes)
print_syscall = 1
}
}
probe kernel.function("copy_process@kernel/fork.c").return
{
if (filter_p()) next;
printf("return %d\n", $return);
try {
if (($return > 0 || $return < -1000) && $return->real_cred && $return->real_cred->user)
printf("good return %d\n", $return);
if (highwatermark_nproc < atomic_read(&$return->real_cred->user->processes)) {
highwatermark_nproc = atomic_read(&$return->real_cred->user->processes)
print_syscall = 1
}
} catch {}
}
/* RLIMIT_NOFILE */
probe kernel.function("__alloc_fd@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
probe kernel.function("do_dup2@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
/* RLIMIT_MEMLOCK */
probe kernel.function("sys_bpf@kernel/bpf/syscall.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_memlock < atomic_long_read(&user->locked_vm) << 12) { # PAGE_SHIFT
highwatermark_memlock = atomic_long_read(&user->locked_vm) << 12
print_syscall = 1
}
}
probe kernel.function("perf_mmap@kernel/events/core.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->pinned_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->pinned_vm << 12
print_syscall = 1
}
}
probe kernel.function("do_mlock@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->locked_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->locked_vm << 12
print_syscall = 1
}
}
probe kernel.function("sys_mlockall@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->total_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_SIGPENDING */
probe kernel.function("__sigqueue_alloc@kernel/signal.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_sigpending < atomic_read(&user->sigpending)) {
highwatermark_sigpending = atomic_read(&user->sigpending)
print_syscall = 1
}
}
/* RLIMIT_MSGGQUEUE */
probe kernel.function("mqueue_get_inode@ipc/mqueue.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_msgqueue < user->mq_bytes) {
highwatermark_msgqueue = user->mq_bytes
print_syscall = 1
}
}
/* RLIMIT_NICE */
probe kernel.function("set_user_nice@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_nice < $nice) {
highwatermark_nice = $nice
print_syscall = 1
}
}
/* RLIMIT_RTPRIO */
probe kernel.function("__sched_setscheduler@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_rtprio < $attr->sched_priority) {
highwatermark_rtprio = $attr->sched_priority
print_syscall = 1
}
}
/* socket address families */
probe kernel.function("__sock_create@net/socket.c").return
{
if (filter_p()) next;
if ($return == 0) {
used_afs |= 1 << $family
print_syscall = 1
} else if ($return == 93) { # EPROTONOSUPPORT
missing_afs |= 1 << $family
print_syscall = 1
}
}
/* mmap flags */
probe kernel.function("do_mmap@mm/mmap.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && ($flags & (2 | 4)) == (2 | 4)) { # PROT_WRITE | PROT_EXEC
no_memory_deny_write_execute = 1
print_syscall = 1
}
}
/* system call printing */
probe nd_syscall.*
{
# TODO: filter out apparently-nested syscalls (that are implemented
# in terms of each other within the kernel); PR6762
if (filter_p()) next;
thread_argstr[tid()]=argstr
if (timestamp || elapsed_time)
thread_time[tid()]=gettimeofday_us()
if (name in syscalls_nonreturn)
report(name,argstr,"")
}
probe nd_syscall.*.return
{
if (filter_p()) next;
report(name,thread_argstr[tid()],retstr)
}
function report(syscall_name, syscall_argstr, syscall_retstr)
{
if (timestamp || elapsed_time)
{
now = gettimeofday_us()
then = thread_time[tid()]
if (timestamp)
prefix=sprintf("%s.%06d ", ctime(then/1000000), then%1000000)
if (elapsed_time && (now>then)) {
diff = now-then
suffix=sprintf(" <%d.%06d>", diff/1000000, diff%1000000)
}
delete thread_time[tid()]
}
/* add a thread-id string in lots of cases, except if
stap strace.stp -c SINGLE_THREADED_CMD */
if (tid() != target()) {
prefix .= sprintf("%s[%d] ", execname(), tid())
}
if (used_caps) {
suffix .= " [Capabilities=" . caps_to_str(used_caps) . "]"
all_used_caps |= used_caps
print_syscall = 1
}
if (missing_caps) {
suffix .= " missing [Capabilities=" . caps_to_str(missing_caps) . "]"
all_missing_caps |= missing_caps
print_syscall = 1
}
foreach ([type, dev] in accessed_devices) {
devs .= dev_to_str(type, dev, accessed_devices[type, dev]) . " "
if (has_devs == 0) {
has_devs = 1
print_syscall = 1
devs = " [DeviceAllow=" . devs
}
all_accessed_devices[type, dev] = accessed_devices[type, dev];
}
if (has_devs) {
devs .= "]"
suffix .= devs
}
if (used_afs) {
suffix .= " [RestrictAddressFamilies=" . afs_to_str(used_afs) . "]"
all_used_afs |= used_afs
print_syscall = 1
}
if (missing_afs) {
suffix .= " missing [RestrictAddressFamilies=" . afs_to_str(missing_afs) . "]"
all_missing_afs |= missing_afs
print_syscall = 1
}
if (no_memory_deny_write_execute) {
suffix .= " [MemoryDenyWriteExecute=false]"
all_memory_deny_write_execute = "false"
}
if (highwatermark_fsize > old_highwatermark_fsize) {
suffix .= sprintf(" [FSIZE %d -> %d]", old_highwatermark_fsize, highwatermark_fsize)
old_highwatermark_fsize = highwatermark_fsize
}
if (highwatermark_data > old_highwatermark_data) {
suffix .= sprintf(" [DATA %d -> %d]", old_highwatermark_data, highwatermark_data)
old_highwatermark_data = highwatermark_data
}
if (highwatermark_stack > old_highwatermark_stack) {
suffix .= sprintf(" [STACK %d -> %d]", old_highwatermark_stack, highwatermark_stack)
old_highwatermark_stack = highwatermark_stack
}
if (highwatermark_core > old_highwatermark_core) {
suffix .= sprintf(" [CORE %d -> %d]", old_highwatermark_core, highwatermark_core)
old_highwatermark_core = highwatermark_core
}
if (highwatermark_nofile > old_highwatermark_nofile) {
suffix .= sprintf(" [NOFILE %d -> %d]", old_highwatermark_nofile, highwatermark_nofile)
old_highwatermark_nofile = highwatermark_nofile
}
if (highwatermark_as > old_highwatermark_as) {
suffix .= sprintf(" [AS %d -> %d]", old_highwatermark_as, highwatermark_as)
old_highwatermark_as = highwatermark_as
}
if (highwatermark_nproc > old_highwatermark_nproc) {
suffix .= sprintf(" [NPROC %d -> %d]", old_highwatermark_nproc, highwatermark_nproc)
old_highwatermark_nproc = highwatermark_nproc
}
if (highwatermark_memlock > old_highwatermark_memlock) {
suffix .= sprintf(" [MEMLOCK %d -> %d]", old_highwatermark_memlock, highwatermark_memlock)
old_highwatermark_memlock = highwatermark_memlock
}
if (highwatermark_sigpending > old_highwatermark_sigpending) {
suffix .= sprintf(" [SIGPENDING %d -> %d]", old_highwatermark_sigpending, highwatermark_sigpending)
old_highwatermark_sigpending = highwatermark_sigpending
}
if (highwatermark_msgqueue > old_highwatermark_msgqueue) {
suffix .= sprintf(" [MSGQUEUE %d -> %d]", old_highwatermark_msgqueue, highwatermark_msgqueue)
old_highwatermark_msgqueue = highwatermark_msgqueue
}
if (highwatermark_nice > old_highwatermark_nice) {
suffix .= sprintf(" [NICE %d -> %d]", old_highwatermark_nice, highwatermark_nice)
old_highwatermark_nice = highwatermark_nice
}
if (highwatermark_rtprio > old_highwatermark_rtprio) {
suffix .= sprintf(" [RTPRIO %d -> %d]", old_highwatermark_rtprio, highwatermark_rtprio)
old_highwatermark_rtprio = highwatermark_rtprio
}
if (!only_capability_use || print_syscall)
printf("%s%s(%s) = %s%s\n",
prefix,
syscall_name, syscall_argstr, syscall_retstr,
suffix)
used_caps = 0
missing_caps = 0
used_afs = 0
print_syscall = 0
no_memory_deny_write_execute = 0
delete accessed_devices
delete thread_argstr[tid()]
}
probe end
{
printf("\nSummary:\n")
printf("CapabilityBoundingSet=%s\n", caps_to_str(all_used_caps))
if (all_missing_caps)
printf("Consider also missing CapabilityBoundingSet=%s\n", caps_to_str(all_missing_caps))
foreach ([type, dev] in all_accessed_devices)
printf("DeviceAllow=%s\n", dev_to_str(type, dev, all_accessed_devices[type, dev]))
printf("LimitFSIZE=%d\n", highwatermark_fsize)
printf("LimitDATA=%d\n", highwatermark_data)
printf("LimitSTACK=%d\n", highwatermark_stack)
printf("LimitCORE=%d\n", highwatermark_core)
printf("LimitNOFILE=%d\n", highwatermark_nofile)
printf("LimitAS=%d\n", highwatermark_as)
printf("LimitNPROC=%d\n", highwatermark_nproc)
printf("LimitMEMLOCK=%d\n", highwatermark_memlock)
printf("LimitSIGPENDING=%d\n", highwatermark_sigpending)
printf("LimitMSGQUEUE=%d\n", highwatermark_msgqueue)
printf("LimitNICE=%d\n", highwatermark_nice)
printf("LimitRTPRIO=%d\n", highwatermark_rtprio)
printf("RestrictAddressFamilies=%s\n", afs_to_str(all_used_afs))
if (all_missing_afs)
printf("Consider also missing RestrictAddressFamilies=%s\n", afs_to_str(all_missing_afs))
printf("MemoryDenyWriteExecute=%s\n", all_memory_deny_write_execute)
}
^ permalink raw reply [flat|nested] 95+ messages in thread* Fwd: Re: [PATCH 00/14] Present useful limits to user (v2)
2016-08-03 18:20 ` Topi Miettinen
(?)
@ 2016-08-04 6:59 ` Topi Miettinen
-1 siblings, 0 replies; 95+ messages in thread
From: Topi Miettinen @ 2016-08-04 6:59 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]
Resending to lkml without cc's.
Hello,
I'm trying the systemtap approach and it looks promising. The script is
annotating strace-like output with capability, device access and RLIMIT
information. In the end there's a summary. Here's sample output from
wpa_supplicant run:
mprotect(0x7efebf140000, 16384, PROT_READ) = 0 [DATA 548864 -> 573440]
[AS 44986368 -> 45002752]
brk(0x55d9611f8000) = 94392125718528 missing
[Capabilities=CAP_SYS_ADMIN] [AS 45002752 -> 45010944]
open(0x55d960716462, O_RDWR) = 3 [DeviceAllow=/dev/char/1:3 rw ]
open("/dev/random", O_RDONLY|O_NONBLOCK) = 3 [DeviceAllow=/dev/char/1:8 r ]
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
[RestrictAddressFamilies=AF_UNIX] [NOFILE 3 -> 4]
open("/etc/wpa_supplicant.conf", O_RDONLY) = 5 [NOFILE 4 -> 5]
socket(PF_NETLINK, SOCK_RAW, 0) = 5 [RestrictAddressFamilies=AF_NETLINK]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 6
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 5 -> 6]
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 7
[RestrictAddressFamilies=AF_NETLINK] [NOFILE 6 -> 7]
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
[RestrictAddressFamilies=AF_INET] [NOFILE 7 -> 8]
open("/dev/rfkill", O_RDONLY) = 9 [DeviceAllow=/dev/char/10:58 r ]
[NOFILE 8 -> 9]
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 10
[RestrictAddressFamilies=AF_UNIX] [NOFILE 9 -> 10]
sendmsg(6, 0x7ffc778f35b0, 0x0) = 36 [Capabilities=CAP_NET_ADMIN]
Summary:
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
Consider also missing CapabilityBoundingSet=CAP_SYS_ADMIN
DeviceAllow=/dev/char/1:3 rw
DeviceAllow=/dev/char/1:8 r
DeviceAllow=/dev/char/10:58 r
DeviceAllow=/dev/char/1:9 r
LimitFSIZE=0
LimitDATA=577536
LimitSTACK=139264
LimitCORE=0
LimitNOFILE=15
LimitAS=45146112
LimitNPROC=171
LimitMEMLOCK=0
LimitSIGPENDING=0
LimitMSGQUEUE=0
LimitNICE=0
LimitRTPRIO=0
RestrictAddressFamilies=AF_UNIX AF_INET AF_NETLINK AF_PACKET
MemoryDenyWriteExecute=true
Some values are not correct. NPROC is wrong because staprun needs to be
run as root instead of the separate privileged user for wpa_supplicant
and that messes user process count. DATA/AS/STACK seems to be a bit off.
I can easily use this as systemd service configuration drop-in otherwise.
Now, the relevant part for the kernel is that I'd like to analyze error
paths better, so the system calls would be also annotated when there's a
failure when a RLIMIT is too tight. It would be easier to insert probes
if there was only one path for RLIMIT checks. Would it be OK to make the
function task_rlimit() a full check against the limit and also make it a
non-inlined function, just for improved probing purposes?
There's already error analysis for the capabilities, but there are some
false positive hits (like brk() complaining about missing CAP_SYS_ADMIN
above).
-Topi
[-- Attachment #2: strace.stp --]
[-- Type: text/plain, Size: 19079 bytes --]
#! /bin/sh
# suppress some run-time errors here for cleaner output
//bin/true && exec stap --suppress-handler-errors --skip-badvars $0 ${1+"$@"}
/*
* Compile:
* stap -p4 -DSTP_NO_OVERLOAD -m strace
* Run:
* /usr/bin/staprun -R -c "/sbin/wpa_supplicant -u -O /run/wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0" -w /root/strace.ko only_capability_use=1 timestamp=0
*/
/* configuration options; set these with stap -G */
global follow_fork = 0 /* -Gfollow_fork=1 means trace descendant processes too */
global timestamp = 1 /* -Gtimestamp=0 means don't print a syscall timestamp */
global elapsed_time = 0 /* -Gelapsed_time=1 means print a syscall duration too */
global only_capability_use = 0 /* -Gonly_capability_use=1 means print only when capabilities are used */
global thread_argstr%
global thread_time%
global syscalls_nonreturn[2]
global capnames[64]
global used_caps
global missing_caps
global all_used_caps
global all_missing_caps
global accessed_devices[1000]
global all_accessed_devices[1000]
global highwatermark_fsize
global highwatermark_data
global highwatermark_stack
global highwatermark_core
global highwatermark_nproc
global highwatermark_nofile
global highwatermark_memlock
global highwatermark_as
global highwatermark_sigpending
global highwatermark_msgqueue
global highwatermark_nice
global highwatermark_rtprio
global old_highwatermark_fsize
global old_highwatermark_data
global old_highwatermark_stack
global old_highwatermark_core
global old_highwatermark_nproc
global old_highwatermark_nofile
global old_highwatermark_memlock
global old_highwatermark_as
global old_highwatermark_sigpending
global old_highwatermark_msgqueue
global old_highwatermark_nice
global old_highwatermark_rtprio
global afnames[64]
global used_afs
global missing_afs
global all_used_afs
global all_missing_afs
global no_memory_deny_write_execute
global all_memory_deny_write_execute = "true"
global print_syscall
probe begin
{
/* list those syscalls that never .return */
syscalls_nonreturn["exit"]=1
syscalls_nonreturn["exit_group"]=1
// grep '#define CAP_.*[0-9]+$' /usr/src/linux-headers*/include/uapi/linux/capability.h | awk '{ print "capnames[" $3 "] = \"" $2 "\";" }'
capnames[0] = "CAP_CHOWN";
capnames[1] = "CAP_DAC_OVERRIDE";
capnames[2] = "CAP_DAC_READ_SEARCH";
capnames[3] = "CAP_FOWNER";
capnames[4] = "CAP_FSETID";
capnames[5] = "CAP_KILL";
capnames[6] = "CAP_SETGID";
capnames[7] = "CAP_SETUID";
capnames[8] = "CAP_SETPCAP";
capnames[9] = "CAP_LINUX_IMMUTABLE";
capnames[10] = "CAP_NET_BIND_SERVICE";
capnames[11] = "CAP_NET_BROADCAST";
capnames[12] = "CAP_NET_ADMIN";
capnames[13] = "CAP_NET_RAW";
capnames[14] = "CAP_IPC_LOCK";
capnames[15] = "CAP_IPC_OWNER";
capnames[16] = "CAP_SYS_MODULE";
capnames[17] = "CAP_SYS_RAWIO";
capnames[18] = "CAP_SYS_CHROOT";
capnames[19] = "CAP_SYS_PTRACE";
capnames[20] = "CAP_SYS_PACCT";
capnames[21] = "CAP_SYS_ADMIN";
capnames[22] = "CAP_SYS_BOOT";
capnames[23] = "CAP_SYS_NICE";
capnames[24] = "CAP_SYS_RESOURCE";
capnames[25] = "CAP_SYS_TIME";
capnames[26] = "CAP_SYS_TTY_CONFIG";
capnames[27] = "CAP_MKNOD";
capnames[28] = "CAP_LEASE";
capnames[29] = "CAP_AUDIT_WRITE";
capnames[30] = "CAP_AUDIT_CONTROL";
capnames[31] = "CAP_SETFCAP";
capnames[32] = "CAP_MAC_OVERRIDE";
capnames[33] = "CAP_MAC_ADMIN";
capnames[34] = "CAP_SYSLOG";
capnames[35] = "CAP_WAKE_ALARM";
capnames[36] = "CAP_BLOCK_SUSPEND";
capnames[37] = "CAP_AUDIT_READ";
//grep '#define AF_.*' /usr/src/linux-headers-*/include/linux/socket.h | awk '{ print "afnames[" $3 "] = \"" $2 "\"" }'
afnames[0] = "AF_UNSPEC"
afnames[1] = "AF_UNIX"
afnames[2] = "AF_INET"
afnames[3] = "AF_AX25"
afnames[4] = "AF_IPX"
afnames[5] = "AF_APPLETALK"
afnames[6] = "AF_NETROM"
afnames[7] = "AF_BRIDGE"
afnames[8] = "AF_ATMPVC"
afnames[9] = "AF_X25"
afnames[10] = "AF_INET6"
afnames[11] = "AF_ROSE"
afnames[12] = "AF_DECnet"
afnames[13] = "AF_NETBEUI"
afnames[14] = "AF_SECURITY"
afnames[15] = "AF_KEY"
afnames[16] = "AF_NETLINK"
afnames[17] = "AF_PACKET"
afnames[18] = "AF_ASH"
afnames[19] = "AF_ECONET"
afnames[20] = "AF_ATMSVC"
afnames[21] = "AF_RDS"
afnames[22] = "AF_SNA"
afnames[23] = "AF_IRDA"
afnames[24] = "AF_PPPOX"
afnames[25] = "AF_WANPIPE"
afnames[26] = "AF_LLC"
afnames[27] = "AF_IB"
afnames[28] = "AF_MPLS"
afnames[29] = "AF_CAN"
afnames[30] = "AF_TIPC"
afnames[31] = "AF_BLUETOOTH"
afnames[32] = "AF_IUCV"
afnames[33] = "AF_RXRPC"
afnames[34] = "AF_ISDN"
afnames[35] = "AF_PHONET"
afnames[36] = "AF_IEEE802154"
afnames[37] = "AF_CAIF"
afnames[38] = "AF_ALG"
afnames[39] = "AF_NFC"
afnames[40] = "AF_VSOCK"
afnames[41] = "AF_KCM"
}
function filter_p()
{
if (target() == 0) return 0; /* system-wide */
if (!follow_fork && pid() != target()) return 1; /* single-process */
if (follow_fork && !target_set_pid(pid())) return 1; /* multi-process */
return 0;
}
function caps_to_str(caps)
{
str = ""
for (i = 0; i < 37; i++) # CAP_LAST_CAP
if (caps & (1 << i)) {
str .= capnames[i]
if ((caps & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
function dev_to_str(type, dev, access)
{
devs = "/dev/"
if (type == 1) # DEV_BLOCK
devs .= "block"
else
devs .= "char"
devs .= sprintf("/%d:%d ", dev >> 32, dev & 0xffffffff)
if (access & 2) # ACC_READ
devs .= "r"
if (access & 4) # ACC_WRITE
devs .= "w"
if (access & 1) # ACC_MKNOD
devs .= "m"
return devs
}
function afs_to_str(afs)
{
str = ""
for (i = 0; i < 42; i++) # MAX_AF
if (afs & (1 << i)) {
str .= afnames[i]
if ((afs & ~((1 << (i + 1)) - 1)) != 0)
str .= " "
}
return str
}
/* Capabilities */
probe kernel.function("cap_capable@security/commoncap.c").return
{
if (filter_p()) next;
if ($return == 0 && $audit)
used_caps |= 1 << $cap;
else
missing_caps |= 1 << $cap;
}
/* Devices */
probe kernel.function("__devcgroup_check_permission@security/device_cgroup.c").return
{
if (filter_p()) next;
if ($return == 0)
accessed_devices[$type, $major << 32 | $minor] |= $access
}
/* RLIMIT_FSIZE */
probe kernel.function("inode_newsize_ok@fs/attr.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_fsize < $offset)
highwatermark_fsize = $offset
}
/* RLIMIT_DATA */
probe kernel.function("prctl_set_mm@kernel/sys.c").return
{
if (filter_p()) next;
if ($return == 0 && highwatermark_data < $prctl_map->end_data - $prctl_map->start_data) {
highwatermark_data = $prctl_map->end_data - $prctl_map->start_data
print_syscall = 1
}
}
probe kernel.function("do_brk@mm/mmap.c").return
{
if (filter_p()) next;
task = task_current()
if ($return > 0 && highwatermark_data < task->mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = task->mm->data_vm << 12
print_syscall = 1
}
if ($return > 0 && highwatermark_as < task->mm->total_vm << 12) {
highwatermark_as = task->mm->total_vm << 12
print_syscall = 1
}
}
/* also RLIMIT_STACK and RLIMIT_MEMLOCK */
probe kernel.function("vm_stat_account@mm/mmap.c").return
{
if (filter_p()) next;
if (highwatermark_data < $mm->data_vm << 12) { # PAGE_SHIFT
highwatermark_data = $mm->data_vm << 12
print_syscall = 1
}
if (highwatermark_stack < $mm->stack_vm << 12) {
highwatermark_stack = $mm->stack_vm << 12
print_syscall = 1
}
if (highwatermark_memlock < atomic_long_read(&$mm->locked_vm) << 12) {
highwatermark_memlock = atomic_long_read(&$mm->locked_vm) << 12
print_syscall = 1
}
if (highwatermark_as < $mm->total_vm << 12) {
highwatermark_as = $mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_CORE */
probe kernel.function("dump_emit@fs/coredump.c").return
{
if (filter_p()) next;
if (highwatermark_core < $cprm->written) {
highwatermark_core = $cprm->written
print_syscall = 1
}
}
/* RLIMIT_NPROC */
probe kernel.function("commit_creds@kernel/cred.c").return
{
if (filter_p()) next;
if (highwatermark_nproc < atomic_read(&$new->user->processes)) {
highwatermark_nproc = atomic_read(&$new->user->processes)
print_syscall = 1
}
}
probe kernel.function("copy_process@kernel/fork.c").return
{
if (filter_p()) next;
printf("return %d\n", $return);
try {
if (($return > 0 || $return < -1000) && $return->real_cred && $return->real_cred->user)
printf("good return %d\n", $return);
if (highwatermark_nproc < atomic_read(&$return->real_cred->user->processes)) {
highwatermark_nproc = atomic_read(&$return->real_cred->user->processes)
print_syscall = 1
}
} catch {}
}
/* RLIMIT_NOFILE */
probe kernel.function("__alloc_fd@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
probe kernel.function("do_dup2@fs/file.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && highwatermark_nofile < $return) {
highwatermark_nofile = $return
print_syscall = 1
}
}
/* RLIMIT_MEMLOCK */
probe kernel.function("sys_bpf@kernel/bpf/syscall.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_memlock < atomic_long_read(&user->locked_vm) << 12) { # PAGE_SHIFT
highwatermark_memlock = atomic_long_read(&user->locked_vm) << 12
print_syscall = 1
}
}
probe kernel.function("perf_mmap@kernel/events/core.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->pinned_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->pinned_vm << 12
print_syscall = 1
}
}
probe kernel.function("do_mlock@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->locked_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->locked_vm << 12
print_syscall = 1
}
}
probe kernel.function("sys_mlockall@mm/mlock.c").return
{
if (filter_p()) next;
task = task_current()
if ($return == 0 && highwatermark_memlock < task->mm->total_vm << 12) { # PAGE_SHIFT
highwatermark_memlock = task->mm->total_vm << 12
print_syscall = 1
}
}
/* RLIMIT_SIGPENDING */
probe kernel.function("__sigqueue_alloc@kernel/signal.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_sigpending < atomic_read(&user->sigpending)) {
highwatermark_sigpending = atomic_read(&user->sigpending)
print_syscall = 1
}
}
/* RLIMIT_MSGGQUEUE */
probe kernel.function("mqueue_get_inode@ipc/mqueue.c").return
{
if (filter_p()) next;
task = task_current()
user = task->real_cred->user
if ($return == 0 && highwatermark_msgqueue < user->mq_bytes) {
highwatermark_msgqueue = user->mq_bytes
print_syscall = 1
}
}
/* RLIMIT_NICE */
probe kernel.function("set_user_nice@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_nice < $nice) {
highwatermark_nice = $nice
print_syscall = 1
}
}
/* RLIMIT_RTPRIO */
probe kernel.function("__sched_setscheduler@kernel/sched/core.c").return
{
if (filter_p()) next;
if (highwatermark_rtprio < $attr->sched_priority) {
highwatermark_rtprio = $attr->sched_priority
print_syscall = 1
}
}
/* socket address families */
probe kernel.function("__sock_create@net/socket.c").return
{
if (filter_p()) next;
if ($return == 0) {
used_afs |= 1 << $family
print_syscall = 1
} else if ($return == 93) { # EPROTONOSUPPORT
missing_afs |= 1 << $family
print_syscall = 1
}
}
/* mmap flags */
probe kernel.function("do_mmap@mm/mmap.c").return
{
if (filter_p()) next;
if (($return >= 0 || $return < -1000) && ($flags & (2 | 4)) == (2 | 4)) { # PROT_WRITE | PROT_EXEC
no_memory_deny_write_execute = 1
print_syscall = 1
}
}
/* system call printing */
probe nd_syscall.*
{
# TODO: filter out apparently-nested syscalls (that are implemented
# in terms of each other within the kernel); PR6762
if (filter_p()) next;
thread_argstr[tid()]=argstr
if (timestamp || elapsed_time)
thread_time[tid()]=gettimeofday_us()
if (name in syscalls_nonreturn)
report(name,argstr,"")
}
probe nd_syscall.*.return
{
if (filter_p()) next;
report(name,thread_argstr[tid()],retstr)
}
function report(syscall_name, syscall_argstr, syscall_retstr)
{
if (timestamp || elapsed_time)
{
now = gettimeofday_us()
then = thread_time[tid()]
if (timestamp)
prefix=sprintf("%s.%06d ", ctime(then/1000000), then%1000000)
if (elapsed_time && (now>then)) {
diff = now-then
suffix=sprintf(" <%d.%06d>", diff/1000000, diff%1000000)
}
delete thread_time[tid()]
}
/* add a thread-id string in lots of cases, except if
stap strace.stp -c SINGLE_THREADED_CMD */
if (tid() != target()) {
prefix .= sprintf("%s[%d] ", execname(), tid())
}
if (used_caps) {
suffix .= " [Capabilities=" . caps_to_str(used_caps) . "]"
all_used_caps |= used_caps
print_syscall = 1
}
if (missing_caps) {
suffix .= " missing [Capabilities=" . caps_to_str(missing_caps) . "]"
all_missing_caps |= missing_caps
print_syscall = 1
}
foreach ([type, dev] in accessed_devices) {
devs .= dev_to_str(type, dev, accessed_devices[type, dev]) . " "
if (has_devs == 0) {
has_devs = 1
print_syscall = 1
devs = " [DeviceAllow=" . devs
}
all_accessed_devices[type, dev] = accessed_devices[type, dev];
}
if (has_devs) {
devs .= "]"
suffix .= devs
}
if (used_afs) {
suffix .= " [RestrictAddressFamilies=" . afs_to_str(used_afs) . "]"
all_used_afs |= used_afs
print_syscall = 1
}
if (missing_afs) {
suffix .= " missing [RestrictAddressFamilies=" . afs_to_str(missing_afs) . "]"
all_missing_afs |= missing_afs
print_syscall = 1
}
if (no_memory_deny_write_execute) {
suffix .= " [MemoryDenyWriteExecute=false]"
all_memory_deny_write_execute = "false"
}
if (highwatermark_fsize > old_highwatermark_fsize) {
suffix .= sprintf(" [FSIZE %d -> %d]", old_highwatermark_fsize, highwatermark_fsize)
old_highwatermark_fsize = highwatermark_fsize
}
if (highwatermark_data > old_highwatermark_data) {
suffix .= sprintf(" [DATA %d -> %d]", old_highwatermark_data, highwatermark_data)
old_highwatermark_data = highwatermark_data
}
if (highwatermark_stack > old_highwatermark_stack) {
suffix .= sprintf(" [STACK %d -> %d]", old_highwatermark_stack, highwatermark_stack)
old_highwatermark_stack = highwatermark_stack
}
if (highwatermark_core > old_highwatermark_core) {
suffix .= sprintf(" [CORE %d -> %d]", old_highwatermark_core, highwatermark_core)
old_highwatermark_core = highwatermark_core
}
if (highwatermark_nofile > old_highwatermark_nofile) {
suffix .= sprintf(" [NOFILE %d -> %d]", old_highwatermark_nofile, highwatermark_nofile)
old_highwatermark_nofile = highwatermark_nofile
}
if (highwatermark_as > old_highwatermark_as) {
suffix .= sprintf(" [AS %d -> %d]", old_highwatermark_as, highwatermark_as)
old_highwatermark_as = highwatermark_as
}
if (highwatermark_nproc > old_highwatermark_nproc) {
suffix .= sprintf(" [NPROC %d -> %d]", old_highwatermark_nproc, highwatermark_nproc)
old_highwatermark_nproc = highwatermark_nproc
}
if (highwatermark_memlock > old_highwatermark_memlock) {
suffix .= sprintf(" [MEMLOCK %d -> %d]", old_highwatermark_memlock, highwatermark_memlock)
old_highwatermark_memlock = highwatermark_memlock
}
if (highwatermark_sigpending > old_highwatermark_sigpending) {
suffix .= sprintf(" [SIGPENDING %d -> %d]", old_highwatermark_sigpending, highwatermark_sigpending)
old_highwatermark_sigpending = highwatermark_sigpending
}
if (highwatermark_msgqueue > old_highwatermark_msgqueue) {
suffix .= sprintf(" [MSGQUEUE %d -> %d]", old_highwatermark_msgqueue, highwatermark_msgqueue)
old_highwatermark_msgqueue = highwatermark_msgqueue
}
if (highwatermark_nice > old_highwatermark_nice) {
suffix .= sprintf(" [NICE %d -> %d]", old_highwatermark_nice, highwatermark_nice)
old_highwatermark_nice = highwatermark_nice
}
if (highwatermark_rtprio > old_highwatermark_rtprio) {
suffix .= sprintf(" [RTPRIO %d -> %d]", old_highwatermark_rtprio, highwatermark_rtprio)
old_highwatermark_rtprio = highwatermark_rtprio
}
if (!only_capability_use || print_syscall)
printf("%s%s(%s) = %s%s\n",
prefix,
syscall_name, syscall_argstr, syscall_retstr,
suffix)
used_caps = 0
missing_caps = 0
used_afs = 0
print_syscall = 0
no_memory_deny_write_execute = 0
delete accessed_devices
delete thread_argstr[tid()]
}
probe end
{
printf("\nSummary:\n")
printf("CapabilityBoundingSet=%s\n", caps_to_str(all_used_caps))
if (all_missing_caps)
printf("Consider also missing CapabilityBoundingSet=%s\n", caps_to_str(all_missing_caps))
foreach ([type, dev] in all_accessed_devices)
printf("DeviceAllow=%s\n", dev_to_str(type, dev, all_accessed_devices[type, dev]))
printf("LimitFSIZE=%d\n", highwatermark_fsize)
printf("LimitDATA=%d\n", highwatermark_data)
printf("LimitSTACK=%d\n", highwatermark_stack)
printf("LimitCORE=%d\n", highwatermark_core)
printf("LimitNOFILE=%d\n", highwatermark_nofile)
printf("LimitAS=%d\n", highwatermark_as)
printf("LimitNPROC=%d\n", highwatermark_nproc)
printf("LimitMEMLOCK=%d\n", highwatermark_memlock)
printf("LimitSIGPENDING=%d\n", highwatermark_sigpending)
printf("LimitMSGQUEUE=%d\n", highwatermark_msgqueue)
printf("LimitNICE=%d\n", highwatermark_nice)
printf("LimitRTPRIO=%d\n", highwatermark_rtprio)
printf("RestrictAddressFamilies=%s\n", afs_to_str(all_used_afs))
if (all_missing_afs)
printf("Consider also missing RestrictAddressFamilies=%s\n", afs_to_str(all_missing_afs))
printf("MemoryDenyWriteExecute=%s\n", all_memory_deny_write_execute)
}
^ permalink raw reply [flat|nested] 95+ messages in thread