BC: resource beancounters (v2)

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +3 -0

@@ -0,0 +1,25 @@
+#
+# Resource beancounters (BC)
+#

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +1 -0

+          The most important resource controlled by this patch is 

unswappable + memory (either mlock'ed or used by internal kernel
structures and + buffers). The main goal of this patch is to
protect processes
+ from running short of important resources because of an
accidental
+ misbehavior of processes or malicious activity aiming to
``kill'' + the system. It's worth to mention that resource limits
configured + by setrlimit(2) do not give an acceptable level of
protection + because they cover only small fraction of resources
and work on a + per-process basis. Per-process accounting doesn't
prevent malicious
+ users from spawning a lot of resource-consuming processes.

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

Quoted 8 lines · Kirill Korotaev

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

...

Quoted 5 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 

arch/sparc64/Kconfig source "security/Kconfig" · line 436

Quoted 3 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

Is it just me, or do these patches look a little funky? Looks like it is trying to patch the same thing into the same file, twice. Also, the patches look to be -p0 instead of -p1.

Quoted 15 lines · Dave Hansen

Quoted 8 lines · Kirill Korotaev

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

...

Quoted 5 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 

Quoted 7 lines

arch/sparc64/Kconfig source "security/Kconfig" · line 436

Quoted 3 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

Is it just me, or do these patches look a little funky? Looks like it is trying to patch the same thing into the same file, twice. Also, the patches look to be -p0 instead of -p1.

They do appear to be -p0

They aren't adding the same thing twice to the same file. This patch
makes different arches source the same Kconfig.

I seem to recall Chandra suggested that instead of doing it this way it
would be more appropriate to add the source line to init/Kconfig because it's more central and arch-independent. I tend to agree.

Quoted 24 lines · On Wed, 23 Aug 2006 15:13:42 -0700 Matt Helsley wrote:

Quoted 15 lines · Dave Hansen

Quoted 8 lines · Kirill Korotaev

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

...

Quoted 5 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 

Quoted 7 lines

arch/sparc64/Kconfig source "security/Kconfig" · line 436

Quoted 3 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

Is it just me, or do these patches look a little funky? Looks like it is trying to patch the same thing into the same file, twice. Also, the patches look to be -p0 instead of -p1.

Quoted 4 lines

They do appear to be -p0

They aren't adding the same thing twice to the same file. This patch
makes different arches source the same Kconfig.

Look again. There are 2 diffstat blocks and 2 of these at least:

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +0 -0

@@ -0,0 +1,25 @@

Quoted 3 lines

I seem to recall Chandra suggested that instead of doing it this way it
would be more appropriate to add the source line to init/Kconfig because it's more central and arch-independent. I tend to agree.

---
~Randy

Quoted 18 lines · Dave Hansen

Quoted 8 lines · Kirill Korotaev

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

...

Quoted 5 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

Quoted 7 lines

arch/sparc64/Kconfig

Quoted 3 lines

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

Is it just me, or do these patches look a little funky? Looks like it is trying to patch the same thing into the same file, twice. Also, the patches look to be -p0 instead of -p1.

They do appear to be -p0

They aren't adding the same thing twice to the same file. This patch
makes different arches source the same Kconfig.

I seem to recall Chandra suggested that instead of doing it this way it
would be more appropriate to add the source line to init/Kconfig because it's more central and arch-independent. I tend to agree.

Quoted 8 lines · Kirill Korotaev

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

...

arch/sparc64/Kconfig

Quoted 8 lines

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

Is it just me, or do these patches look a little funky? Looks like it is trying to patch the same thing into the same file, twice. Also, the patches look to be -p0 instead of -p1.

I'm having a few problems applying them.

Add kernel/bc/Kconfig file with BC options and include it into arch Kconfigs

Signed-off-by Pavel Emelianov <[email protected]>

Signed-off-by Kirill Korotaev <[email protected]>

---

 arch/i386/Kconfig    |    2 ++
 arch/ia64/Kconfig    |    2 ++
 arch/powerpc/Kconfig |    2 ++
 arch/ppc/Kconfig     |    2 ++
 arch/sparc/Kconfig   |    2 ++
 arch/sparc64/Kconfig |    2 ++
 arch/x86_64/Kconfig  |    2 ++
 kernel/bc/Kconfig    |   25 +++++++++++++++++++++++++
 8 files changed, 39 insertions(+)

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +2 -0

@@ -1146,6 +1146,8 @@ source "crypto/Kconfig"
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 #
 # Use the generic interrupt handling code in kernel/irq/:
 #

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +2 -0

@@ -481,6 +481,8 @@ source "fs/Kconfig"
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 #
 # Use the generic interrupt handling code in kernel/irq/:
 #Add kernel/bc/Kconfig file with BC options and

include it into arch Kconfigs

Signed-off-by Pavel Emelianov <[email protected]>

Signed-off-by Kirill Korotaev <[email protected]>

---

 arch/i386/Kconfig    |    2 ++
 arch/ia64/Kconfig    |    2 ++
 arch/powerpc/Kconfig |    2 ++
 arch/ppc/Kconfig     |    2 ++
 arch/sparc/Kconfig   |    2 ++
 arch/sparc64/Kconfig |    2 ++
 arch/x86_64/Kconfig  |    2 ++
 kernel/bc/Kconfig    |   25 +++++++++++++++++++++++++
 8 files changed, 39 insertions(+)

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +2 -0

@@ -1146,6 +1146,8 @@ source "crypto/Kconfig"
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 #
 # Use the generic interrupt handling code in kernel/irq/:
 #

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +2 -0

@@ -481,6 +481,8 @@ source "fs/Kconfig"
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 #
 # Use the generic interrupt handling code in kernel/irq/:
 #

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +2 -0

@@ -1038,6 +1038,8 @@ source "arch/powerpc/platforms/iseries/K
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 menu "Instrumentation Support"
         depends on EXPERIMENTAL
 

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +2 -0

@@ -1414,6 +1414,8 @@ endmenu
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 source "arch/powerpc/oprofile/Kconfig"
 
 source "arch/ppc/Kconfig.debug"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +2 -0

@@ -296,3 +296,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +2 -0

@@ -655,3 +655,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +25 -0

@@ -0,0 +1,25 @@
+#
+# Resource beancounters (BC)
+#
+# Copyright (C) 2006 OpenVZ. SWsoft Inc
+
+menu "User resources"
+
+config BEANCOUNTERS
+	bool "Enable resource accounting/control"
+	default n
+	help 
+          This patch provides accounting and allows to configure
+          limits for user's consumption of exhaustible system resources.
+          The most important resource controlled by this patch is unswappable 
+          memory (either mlock'ed or used by internal kernel structures and 
+          buffers). The main goal of this patch is to protect processes
+          from running short of important resources because of an accidental
+          misbehavior of processes or malicious activity aiming to ``kill'' 
+          the system. It's worth to mention that resource limits configured 
+          by setrlimit(2) do not give an acceptable level of protection 
+          because they cover only small fraction of resources and work on a 
+          per-process basis.  Per-process accounting doesn't prevent malicious
+          users from spawning a lot of resource-consuming processes.
+
+endmenu

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +2 -0

@@ -1038,6 +1038,8 @@ source "arch/powerpc/platforms/iseries/K
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 menu "Instrumentation Support"
         depends on EXPERIMENTAL
 

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +2 -0

@@ -1414,6 +1414,8 @@ endmenu
 
 source "lib/Kconfig"
 
+source "kernel/bc/Kconfig"
+
 source "arch/powerpc/oprofile/Kconfig"
 
 source "arch/ppc/Kconfig.debug"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +2 -0

@@ -296,3 +296,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +2 -0

@@ -655,3 +655,5 @@ source "security/Kconfig"
 source "crypto/Kconfig"
 
 source "lib/Kconfig"
+
+source "kernel/bc/Kconfig"

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +25 -0

@@ -0,0 +1,25 @@
+#
+# Resource beancounters (BC)
+#
+# Copyright (C) 2006 OpenVZ. SWsoft Inc
+
+menu "User resources"
+
+config BEANCOUNTERS
+	bool "Enable resource accounting/control"
+	default n
+	help 
+          This patch provides accounting and allows to configure
+          limits for user's consumption of exhaustible system resources.
+          The most important resource controlled by this patch is unswappable 
+          memory (either mlock'ed or used by internal kernel structures and 
+          buffers). The main goal of this patch is to protect processes
+          from running short of important resources because of an accidental
+          misbehavior of processes or malicious activity aiming to ``kill'' 
+          the system. It's worth to mention that resource limits configured 
+          by setrlimit(2) do not give an acceptable level of protection 
+          because they cover only small fraction of resources and work on a 
+          per-process basis.  Per-process accounting doesn't prevent malicious
+          users from spawning a lot of resource-consuming processes.
+
+endmenu

Is there a reason why these can be moved to a arch-neutral place ?

PS: Please keep ckrm-tech on Cc: please.

Quoted 229 lines

Add kernel/bc/Kconfig file with BC options and include it into arch Kconfigs

Signed-off-by Pavel Emelianov <[email protected]>

Signed-off-by Kirill Korotaev <[email protected]>

---

arch/i386/Kconfig    |    2 ++
arch/ia64/Kconfig    |    2 ++
arch/powerpc/Kconfig |    2 ++
arch/ppc/Kconfig     |    2 ++
arch/sparc/Kconfig   |    2 ++
arch/sparc64/Kconfig |    2 ++
arch/x86_64/Kconfig  |    2 ++
kernel/bc/Kconfig    |   25 +++++++++++++++++++++++++
8 files changed, 39 insertions(+)

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +0 -0

@@ -1146,6 +1146,8 @@ source "crypto/Kconfig"
 

source "lib/Kconfig"

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +2 -0

+source "kernel/bc/Kconfig"
+

#
# Use the generic interrupt handling code in kernel/irq/:
#

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +0 -0

@@ -481,6 +481,8 @@ source "fs/Kconfig"
 

source "lib/Kconfig"

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +2 -0

+source "kernel/bc/Kconfig"
+

#
# Use the generic interrupt handling code in kernel/irq/:
#Add kernel/bc/Kconfig file with BC options and include it into arch Kconfigs

Signed-off-by Pavel Emelianov <[email protected]>

Signed-off-by Kirill Korotaev <[email protected]>

---

arch/i386/Kconfig    |    2 ++
arch/ia64/Kconfig    |    2 ++
arch/powerpc/Kconfig |    2 ++
arch/ppc/Kconfig     |    2 ++
arch/sparc/Kconfig   |    2 ++
arch/sparc64/Kconfig |    2 ++
arch/x86_64/Kconfig  |    2 ++
kernel/bc/Kconfig    |   25 +++++++++++++++++++++++++
8 files changed, 39 insertions(+)

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +0 -0

@@ -1146,6 +1146,8 @@ source "crypto/Kconfig"
 

source "lib/Kconfig"

arch/i386/Kconfig renamed from arch/i386/Kconfig.bckm +2 -0

+source "kernel/bc/Kconfig"
+

#
# Use the generic interrupt handling code in kernel/irq/:
#

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +0 -0

@@ -481,6 +481,8 @@ source "fs/Kconfig"
 

source "lib/Kconfig"

arch/ia64/Kconfig renamed from arch/ia64/Kconfig.bckm +2 -0

+source "kernel/bc/Kconfig"
+

#
# Use the generic interrupt handling code in kernel/irq/:
#

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +0 -0

@@ -1038,6 +1038,8 @@ source "arch/powerpc/platforms/iseries/K
 

source "lib/Kconfig"

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +2 -0

+source "kernel/bc/Kconfig"
+

menu "Instrumentation Support"
depends on EXPERIMENTAL

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +0 -0

@@ -1414,6 +1414,8 @@ endmenu
 

source "lib/Kconfig"

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +2 -0

+source "kernel/bc/Kconfig"
+

source "arch/powerpc/oprofile/Kconfig"

source "arch/ppc/Kconfig.debug"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +0 -0

@@ -296,3 +296,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +0 -0

@@ -655,3 +655,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +2 -0

+
+source "kernel/bc/Kconfig"

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +25 -0

@@ -0,0 +1,25 @@
+#
+# Resource beancounters (BC)
+#
+# Copyright (C) 2006 OpenVZ. SWsoft Inc
+
+menu "User resources"
+
+config BEANCOUNTERS
+	bool "Enable resource accounting/control"
+	default n
+	help 
+          This patch provides accounting and allows to configure
+          limits for user's consumption of exhaustible system resources.
+          The most important resource controlled by this patch is unswappable 
+          memory (either mlock'ed or used by internal kernel structures and 
+          buffers). The main goal of this patch is to protect processes
+          from running short of important resources because of an accidental
+          misbehavior of processes or malicious activity aiming to ``kill'' 
+          the system. It's worth to mention that resource limits configured 
+          by setrlimit(2) do not give an acceptable level of protection 
+          because they cover only small fraction of resources and work on a 
+          per-process basis.  Per-process accounting doesn't prevent malicious
+          users from spawning a lot of resource-consuming processes.
+
+endmenu

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +0 -0

@@ -1038,6 +1038,8 @@ source "arch/powerpc/platforms/iseries/K
 

source "lib/Kconfig"

arch/powerpc/Kconfig renamed from arch/powerpc/Kconfig.arkcfg +2 -0

+source "kernel/bc/Kconfig"
+

menu "Instrumentation Support"
depends on EXPERIMENTAL

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +0 -0

@@ -1414,6 +1414,8 @@ endmenu
 

source "lib/Kconfig"

arch/ppc/Kconfig renamed from arch/ppc/Kconfig.arkcfg +2 -0

+source "kernel/bc/Kconfig"
+

source "arch/powerpc/oprofile/Kconfig"

source "arch/ppc/Kconfig.debug"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +0 -0

@@ -296,3 +296,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc/Kconfig renamed from arch/sparc/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +0 -0

@@ -432,3 +432,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/sparc64/Kconfig renamed from arch/sparc64/Kconfig.arkcfg +2 -0

+
+source "kernel/bc/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +0 -0

@@ -655,3 +655,5 @@ source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"

arch/x86_64/Kconfig renamed from arch/x86_64/Kconfig.bckm +2 -0

+
+source "kernel/bc/Kconfig"

kernel/bc/Kconfig renamed from kernel/bc/Kconfig.bckm +25 -0

@@ -0,0 +1,25 @@
+#
+# Resource beancounters (BC)
+#
+# Copyright (C) 2006 OpenVZ. SWsoft Inc
+
+menu "User resources"
+
+config BEANCOUNTERS
+	bool "Enable resource accounting/control"
+	default n
+	help 
+          This patch provides accounting and allows to configure
+          limits for user's consumption of exhaustible system resources.
+          The most important resource controlled by this patch is unswappable 
+          memory (either mlock'ed or used by internal kernel structures and 
+          buffers). The main goal of this patch is to protect processes
+          from running short of important resources because of an accidental
+          misbehavior of processes or malicious activity aiming to ``kill'' 
+          the system. It's worth to mention that resource limits configured 
+          by setrlimit(2) do not give an acceptable level of protection 
+          because they cover only small fraction of resources and work on a 
+          per-process basis.  Per-process accounting doesn't prevent malicious
+          users from spawning a lot of resource-consuming processes.
+
+endmenu

Quoted 1 line

Is there a reason why these can be moved to a arch-neutral place ?

I think a good place for BC would be kernel/Kconfig.bc

but still this should be added into archs.
ok?

Quoted 1 line

PS: Please keep ckrm-tech on Cc: please.

Sorry, it is very hard to track emails coming from authors and 3 mailing lists.

Better tell me the interested people emails.

include/bc/beancounter.h line 74

Quoted 3 lines · Kirill Korotaev

include/bc/beancounter.h new file +3 -0

+#ifdef CONFIG_BEANCOUNTERS
+extern struct hlist_head bc_hash[];
+extern spinlock_t bc_hash_lock;

I wonder who pokes into that hash from other files? Looks a bit dangerous.

include/bc/beancounter.h line 115

Quoted 5 lines

include/bc/beancounter.h new file +5 -0

+void __put_beancounter(struct beancounter *bc);
+static inline void put_beancounter(struct beancounter *bc)
+{
+	__put_beancounter(bc);
+}

The wrapper seems pointless too.

The file could use a overview comment what the various counter types actually are.

kernel/bc/beancounter.c line 105

Quoted 2 lines

kernel/bc/beancounter.c new file +2 -0

+	bc_print_id(bc, uid, sizeof(uid));
+	printk(KERN_WARNING "BC %s %s warning: %s "

Doesn't this need some rate limiting? Or can it be only triggered by code bugs?

kernel/bc/beancounter.c line 288

Quoted 2 lines

kernel/bc/beancounter.c new file +2 -0

+	bc = &default_beancounter;
+	memset(bc, 0, sizeof(default_beancounter));

You don't trust the BSS to be zero? @)

Quoted 9 lines · Andi Kleen

include/bc/beancounter.h line 74

Quoted 3 lines · Kirill Korotaev

include/bc/beancounter.h new file +3 -0

+#ifdef CONFIG_BEANCOUNTERS
+extern struct hlist_head bc_hash[];
+extern spinlock_t bc_hash_lock;

I wonder who pokes into that hash from other files? Looks a bit dangerous.

it was kernel/ub/proc.c with proc interface :)
however, we removed it from this patchset version, but forgot extern's...

will remove

Quoted 8 lines

include/bc/beancounter.h line 115

Quoted 5 lines

include/bc/beancounter.h new file +5 -0

+void __put_beancounter(struct beancounter *bc);
+static inline void put_beancounter(struct beancounter *bc)
+{
+	__put_beancounter(bc);
+}

The wrapper seems pointless too.

yep, almost the same reason :)

Quoted 2 lines

The file could use a overview comment what the various counter types actually are.

you mean comment about what resource parameters we introduce?

+/*
+ * Kernel internal part.
+ */

kernel/bc/beancounter.c new file +12 -0

+		return;
+	}
+
+	BUG_ON(bc == &init_bc);
+	verify_held(bc);
+	hlist_del(&bc->hash);
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+	kmem_cache_free(bc_cachep, bc);
+}
+
+EXPORT_SYMBOL(__put_beancounter);
 
+int bc_charge_locked(struct beancounter *bc, int resource, unsigned long 

val,

kernel/bc/beancounter.c new file +4 -0

+		enum severity strict)
+{
+	/*
+	 * bc_value <= BC_MAXVALUE, value <= BC_MAXVALUE, and only one 

addition

include/bc/beancounter.h

Quoted 5 lines · Kirill Korotaev

include/bc/beancounter.h new file +1 -0

 
 
+#define BC_RESOURCES	0

Do you want userspace to see it?

Quoted 6 lines

include/bc/beancounter.h new file +6 -0

+struct bc_resource_parm {
+	unsigned long barrier;	/* A barrier over which resource allocations
+				 * are failed gracefully. e.g. if the amount
+				 * of consumed memory is over the barrier
+				 * further sbrk() or mmap() calls fail, the
+				 * existing processes are not killed.

include/bc/beancounter.h line 27

Quoted 5 lines

include/bc/beancounter.h new file +5 -0

+				 */
+	unsigned long limit;	/* hard resource limit */
+	unsigned long held;	/* consumed resources */
+	unsigned long maxheld;	/* maximum amount of consumed resources */
+	unsigned long minheld;	/* minumum amount of consumed resources */

Stupid question: when minimum amount is useful?

Quoted 3 lines

+/*
+ * Kernel internal part.
+ */

Redundant comment, YMMV.

include/bc/beancounter.h line 37

Quoted 3 lines

include/bc/beancounter.h new file +3 -0

+#ifdef __KERNEL__
+
+#include <linux/config.h>

config.h is unneeded. You can drop it from everywhere.

include/bc/beancounter.h

Quoted 2 lines

include/bc/beancounter.h new file +2 -0

+struct beancounter
+{

nit:
"struct beancounter {"

include/bc/beancounter.h line 64

Quoted 10 lines

include/bc/beancounter.h new file +10 -0

+	atomic_t		bc_refcount;
+	spinlock_t		bc_lock;
+	uid_t			bc_id;
+	struct hlist_node	hash;
+
+	/* resources statistics and settings */
+	struct bc_resource_parm	bc_parms[BC_RESOURCES];
+};
+
+enum severity { BC_BARRIER, BC_LIMIT, BC_FORCE };

bc_severity?

Quoted 4 lines

kernel/bc/beancounter.c new file +0 -0

kernel/bc/beancounter.c line 30

Quoted 7 lines

kernel/bc/beancounter.c new file +7 -0

+#define bc_hash_fun(x) ((((x) >> 8) ^ (x)) & (BC_HASH_SIZE - 1))
+
+struct hlist_head bc_hash[BC_HASH_SIZE];
+spinlock_t bc_hash_lock;
+
+EXPORT_SYMBOL(bc_hash);
+EXPORT_SYMBOL(bc_hash_lock);

tasklist_lock was unexported recently and this looks equally low-level. I couldn't find place in patchbomb where you use it in modular fashion. perhaps, i need more sleep.

Quoted 8 lines

kernel/bc/beancounter.c new file +8 -0

+void __put_beancounter(struct beancounter *bc)
+{
+	unsigned long flags;
+
+	/* equivalent to atomic_dec_and_lock_irqsave() */
+	local_irq_save(flags);
+	if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
+		local_irq_restore(flags);

kernel/bc/beancounter.c line 135

Quoted 5 lines

kernel/bc/beancounter.c new file +5 -0

+		if (unlikely(atomic_read(&bc->bc_refcount) < 0))
+			printk(KERN_ERR "BC: Bad refcount: bc=%p, "
+					"luid=%d, ref=%d\n",
+					bc, bc->bc_id,
+					atomic_read(&bc->bc_refcount));

Should this BUG_ON() ?

Quoted 20 lines

kernel/bc/beancounter.c new file +12 -0

+		return;
+	}
+
+	BUG_ON(bc == &init_bc);
+	verify_held(bc);
+	hlist_del(&bc->hash);
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+	kmem_cache_free(bc_cachep, bc);
+}
+
+EXPORT_SYMBOL(__put_beancounter);
 
 
+int bc_charge_locked(struct beancounter *bc, int resource, unsigned long 

val,

kernel/bc/beancounter.c new file +4 -0

+		enum severity strict)
+{
+	/*
+	 * bc_value <= BC_MAXVALUE, value <= BC_MAXVALUE, and only one 

addition

kernel/bc/beancounter.c line 162

Quoted 6 lines

kernel/bc/beancounter.c new file +6 -0

+	 * at the moment is possible so an overflow is impossible.  
+	 */
+	bc->bc_parms[resource].held += val;
+
+	switch (strict) {
+		case BC_BARRIER:

nit: one tab less

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 8 lines

Quoted 8 lines

kernel/bc/beancounter.c new file +8 -0

+void __put_beancounter(struct beancounter *bc)
+{
+	unsigned long flags;
+
+	/* equivalent to atomic_dec_and_lock_irqsave() */
+	local_irq_save(flags);
+	if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
+		local_irq_restore(flags);

Quoted 8 lines

kernel/bc/beancounter.c line 135

Quoted 5 lines

kernel/bc/beancounter.c new file +5 -0

+		if (unlikely(atomic_read(&bc->bc_refcount) < 0))
+			printk(KERN_ERR "BC: Bad refcount: bc=%p, "
+					"luid=%d, ref=%d\n",
+					bc, bc->bc_id,
+					atomic_read(&bc->bc_refcount));

Should this BUG_ON() ?

BUG_ON doesn't print much information :)
ok, will replace

Quoted 11 lines · Alexey Dobriyan

include/bc/beancounter.h

Quoted 5 lines · Kirill Korotaev

include/bc/beancounter.h new file +1 -0

 
 
+#define BC_RESOURCES	0

Do you want userspace to see it?

yep.

Quoted 6 lines

Quoted 6 lines

include/bc/beancounter.h new file +6 -0

+struct bc_resource_parm {
+	unsigned long barrier;	/* A barrier over which resource allocations
+				 * are failed gracefully. e.g. if the amount
+				 * of consumed memory is over the barrier
+				 * further sbrk() or mmap() calls fail, the
+				 * existing processes are not killed.

Quoted 8 lines

include/bc/beancounter.h line 27

Quoted 5 lines

include/bc/beancounter.h new file +5 -0

+				 */
+	unsigned long limit;	/* hard resource limit */
+	unsigned long held;	/* consumed resources */
+	unsigned long maxheld;	/* maximum amount of consumed resources */
+	unsigned long minheld;	/* minumum amount of consumed resources */

Stupid question: when minimum amount is useful?

to monitor usage statistics (range of used resources). this value will be usefull when ubstat will be added. this field probably would be more logical to add later, but since it is part of user space interface it is left here for not changing API later.

Core functionality and interfaces of BC:
find/create beancounter, initialization, charge/uncharge of resource, core objects' declarations.

Basic structures:
bc_resource_parm - resource description
beancounter - set of resources, id, lock

..

+enum severity { BC_BARRIER, BC_LIMIT, BC_FORCE };

+#define bc_hash_fun(x) ((((x) >> 8) ^ (x)) & (BC_HASH_SIZE - 1))

kernel/bc/beancounter.c new file +51 -0

+/*
+ *	Per resource beancounting. Resources are tied to their luid.
+ *	The resource structure itself is tagged both to the process and
+ *	the charging resources (a socket doesn't want to have to search for
+ *	things at irq time for example). Reference counters keep things in
+ *	hand.
+ *
+ *	The case where a user creates resource, kills all his processes and
+ *	then starts new ones is correctly handled this way. The refcounters
+ *	will mean the old entry is still around with resource tied to it.
+ */
+
+struct beancounter *beancounter_findcreate(uid_t uid, int mask)
+{
+	struct beancounter *new_bc, *bc;
+	unsigned long flags;
+	struct hlist_head *slot;
+	struct hlist_node *pos;
+
+	slot = &bc_hash[bc_hash_fun(uid)];
+	new_bc = NULL;
+
+retry:
+	spin_lock_irqsave(&bc_hash_lock, flags);
+	hlist_for_each_entry (bc, pos, slot, hash)
+		if (bc->bc_id == uid)
+			break;
+
+	if (pos != NULL) {
+		get_beancounter(bc);
+		spin_unlock_irqrestore(&bc_hash_lock, flags);
+
+		if (new_bc != NULL)
+			kmem_cache_free(bc_cachep, new_bc);
+		return bc;
+	}
+
+	if (!(mask & BC_ALLOC))
+		goto out_unlock;
+
+	if (new_bc != NULL)
+		goto out_install;
+
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+
+	new_bc = kmem_cache_alloc(bc_cachep,
+			mask & BC_ALLOC_ATOMIC ? GFP_ATOMIC : GFP_KERNEL);
+	if (new_bc == NULL)
+		goto out;
+
+	memcpy(new_bc, &default_beancounter, sizeof(*new_bc));

kernel/bc/beancounter.c new file +22 -0

+static inline void verify_held(struct beancounter *bc)
+{
+	int i;
+
+	for (i = 0; i < BC_RESOURCES; i++)
+		if (bc->bc_parms[i].held != 0)
+			bc_print_resource_warning(bc, i,
+					"resource is held on put", 0, 0);
+}
+
+void __put_beancounter(struct beancounter *bc)
+{
+	unsigned long flags;
+
+	/* equivalent to atomic_dec_and_lock_irqsave() */
+	local_irq_save(flags);
+	if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
+		local_irq_restore(flags);
+		if (unlikely(atomic_read(&bc->bc_refcount) < 0))
+			printk(KERN_ERR "BC: Bad refcount: bc=%p, "
+					"luid=%d, ref=%d\n",
+					bc, bc->bc_id,

Quoted 16 lines · On Wed, 23 Aug 2006 15:03:07 +0400 Kirill Korotaev <[email protected]> wrote:

kernel/bc/beancounter.c new file +16 -0

+void __put_beancounter(struct beancounter *bc)
+{
+	unsigned long flags;
+
+	/* equivalent to atomic_dec_and_lock_irqsave() */
+	local_irq_save(flags);
+	if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
+		local_irq_restore(flags);
+		if (unlikely(atomic_read(&bc->bc_refcount) < 0))
+			printk(KERN_ERR "BC: Bad refcount: bc=%p, "
+					"luid=%d, ref=%d\n",
+					bc, bc->bc_id,
+					atomic_read(&bc->bc_refcount));
+		return;
+	}
+

kernel/bc/beancounter.c line 144

Quoted 6 lines

kernel/bc/beancounter.c new file +6 -0

+	BUG_ON(bc == &init_bc);
+	verify_held(bc);
+	hlist_del(&bc->hash);
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+	kmem_cache_free(bc_cachep, bc);
+}

I wonder if it's safe and worthwhile to optimise away the local_irq_save():

	if (atomic_dec_and_test(&bc->bc_refcount)) {

		spin_lock_irqsave(&bc_hash_lock, flags);
		if (atomic_read(&bc->bc_refcount) == 0) {

free it

Quoted 2 lines

+#define bc_charge_locked(bc, r, v, s) (0)

Quoted 1 line

+#define bc_charge(bc, r, v) (0)

akpm:/home/akpm> cat t.c
void foo(void)

{
	(0);
}

akpm:/home/akpm> gcc -c -Wall t.c
t.c: In function 'foo':
t.c:4: warning: statement with no effect

Quoted 44 lines

kernel/bc/beancounter.c new file +44 -0

+struct beancounter *beancounter_findcreate(uid_t uid, int mask)
+{
+	struct beancounter *new_bc, *bc;
+	unsigned long flags;
+	struct hlist_head *slot;
+	struct hlist_node *pos;
+
+	slot = &bc_hash[bc_hash_fun(uid)];
+	new_bc = NULL;
+
+retry:
+	spin_lock_irqsave(&bc_hash_lock, flags);
+	hlist_for_each_entry (bc, pos, slot, hash)
+		if (bc->bc_id == uid)
+			break;
+
+	if (pos != NULL) {
+		get_beancounter(bc);
+		spin_unlock_irqrestore(&bc_hash_lock, flags);
+
+		if (new_bc != NULL)
+			kmem_cache_free(bc_cachep, new_bc);
+		return bc;
+	}
+
+	if (!(mask & BC_ALLOC))
+		goto out_unlock;
+
+	if (new_bc != NULL)
+		goto out_install;
+
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+
+	new_bc = kmem_cache_alloc(bc_cachep,
+			mask & BC_ALLOC_ATOMIC ? GFP_ATOMIC : GFP_KERNEL);
+	if (new_bc == NULL)
+		goto out;
+
+	memcpy(new_bc, &default_beancounter, sizeof(*new_bc));
+	init_beancounter_struct(new_bc, uid);
+	goto retry;
+
+out_install:
+	hlist_add_head(&new_bc->hash, slot);

kernel/bc/beancounter.c line 92

Quoted 5 lines

kernel/bc/beancounter.c new file +5 -0

+out_unlock:
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+out:
+	return new_bc;
+}

Can remove the global bc_hash_lock and make the locking per-hash-bucket.

Quoted 22 lines

kernel/bc/beancounter.c new file +22 -0

+static inline void verify_held(struct beancounter *bc)
+{
+	int i;
+
+	for (i = 0; i < BC_RESOURCES; i++)
+		if (bc->bc_parms[i].held != 0)
+			bc_print_resource_warning(bc, i,
+					"resource is held on put", 0, 0);
+}
+
+void __put_beancounter(struct beancounter *bc)
+{
+	unsigned long flags;
+
+	/* equivalent to atomic_dec_and_lock_irqsave() */
+	local_irq_save(flags);
+	if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
+		local_irq_restore(flags);
+		if (unlikely(atomic_read(&bc->bc_refcount) < 0))
+			printk(KERN_ERR "BC: Bad refcount: bc=%p, "
+					"luid=%d, ref=%d\n",
+					bc, bc->bc_id,

kernel/bc/beancounter.c line 144

Quoted 10 lines

kernel/bc/beancounter.c new file +10 -0

+					atomic_read(&bc->bc_refcount));
+		return;
+	}
+
+	BUG_ON(bc == &init_bc);
+	verify_held(bc);
+	hlist_del(&bc->hash);
+	spin_unlock_irqrestore(&bc_hash_lock, flags);
+	kmem_cache_free(bc_cachep, bc);
+}

I wonder if it's safe and worthwhile to optimise away the local_irq_save():

	if (atomic_dec_and_test(&bc->bc_refcount)) {
		spin_lock_irqsave(&bc_hash_lock, flags);
		if (atomic_read(&bc->bc_refcount) == 0) {
			free it

Quoted 11 lines

Quoted 2 lines

+#define bc_charge_locked(bc, r, v, s) (0)

Quoted 1 line

+#define bc_charge(bc, r, v) (0)

akpm:/home/akpm> cat t.c
void foo(void)

{
	(0);
}

akpm:/home/akpm> gcc -c -Wall t.c
t.c: In function 'foo':
t.c:4: warning: statement with no effect

these functions return value should always be checked (!).

i.e. it is never called like:
ub_charge(bc, r, v);

Quoted 13 lines · On Thu, 24 Aug 2006 16:06:11 +0400 Kirill Korotaev <[email protected]> wrote:

Quoted 4 lines

Quoted 3 lines

+#define bc_charge_locked(bc, r, v, s) (0)

Quoted 1 line

+#define bc_charge(bc, r, v) (0)

Quoted 8 lines

akpm:/home/akpm> cat t.c
void foo(void)

{
	(0);
}

akpm:/home/akpm> gcc -c -Wall t.c
t.c: In function 'foo':
t.c:4: warning: statement with no effect

Quoted 1 line

these functions return value should always be checked (!).

We have __must_check for that.

Quoted 2 lines

i.e. it is never called like:
ub_charge(bc, r, v);

Also...

if (bc_charge(tpyo, undefined_variable, syntax_error))

will happily compile if !CONFIG_BEANCOUNTER.

Turning these stubs into static inline __must_check functions fixes all this.

kernel/bc/beancounter.c new file +17 -0

+struct beancounter *beancounter_findcreate(uid_t uid, int mask)
+{
+	struct beancounter *new_bc, *bc;
+	unsigned long flags;
+	struct hlist_head *slot;
+	struct hlist_node *pos;
+
+	slot = &bc_hash[bc_hash_fun(uid)];
+	new_bc = NULL;
+
+retry:
+	spin_lock_irqsave(&bc_hash_lock, flags);
+	hlist_for_each_entry (bc, pos, slot, hash)
+		if (bc->bc_id == uid)
+			break;
+
+	if (pos != NULL) {

kernel/bc/sys.c line 53

Quoted 2 lines · On Wed, 23 Aug 2006 17:43:16 +0400 Kirill Korotaev <[email protected]> wrote:

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +2 -0

+asmlinkage long sys_set_bclimit(uid_t id, unsigned long resource,
+		unsigned long *limits)

I'm still a bit mystified about the use of uid_t here. It's not a uid, is it?

Ar Mer, 2006-08-23 am 09:50 -0700, ysgrifennodd Andrew Morton:

Quoted 3 lines

On Wed, 23 Aug 2006 17:43:16 +0400
Kirill Korotaev <[email protected]> wrote:

Quoted 5 lines

kernel/bc/sys.c line 53

Quoted 2 lines

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +2 -0

+asmlinkage long sys_set_bclimit(uid_t id, unsigned long resource,
+		unsigned long *limits)

I'm still a bit mystified about the use of uid_t here. It's not a uid, is it?

Its a uid_t because of setluid() and twenty odd years of existing unix practice.

Quoted 3 lines

Its a uid_t because of setluid() and twenty odd years of existing unix practice.

I don't understand. This number is an identifier for an accounting container, which was somehow dreamed up by userspace.

Ar Mer, 2006-08-23 am 21:35 -0700, ysgrifennodd Andrew Morton:

Quoted 6 lines

Quoted 3 lines

Its a uid_t because of setluid() and twenty odd years of existing unix practice.

I don't understand. This number is an identifier for an accounting container, which was somehow dreamed up by userspace.

Which happens to be a uid_t. It could easily be anyother_t of itself and you can create a container_id_t or whatever. It is just a number.

The ancient Unix implementations of this kind of resource management and security are built around setluid() which sets a uid value that cannot be changed again and is normally used for security purposes. That happened to be a uid_t and in simple setups at login uid = luid = euid would be the norm.

Thus the Linux one happens to be a uid_t. It could be something else but for the "container per user" model whatever a container is must be able to hold all possible uid_t values. So we can certainly do something like

typedef uid_t container_id_t;

Quoted 22 lines · Alan Cox

Ar Mer, 2006-08-23 am 21:35 -0700, ysgrifennodd Andrew Morton:

Quoted 6 lines

Quoted 3 lines

Its a uid_t because of setluid() and twenty odd years of existing unix practice.

I don't understand. This number is an identifier for an accounting container, which was somehow dreamed up by userspace.

Which happens to be a uid_t. It could easily be anyother_t of itself and you can create a container_id_t or whatever. It is just a number.

The ancient Unix implementations of this kind of resource management and security are built around setluid() which sets a uid value that cannot be changed again and is normally used for security purposes. That happened to be a uid_t and in simple setups at login uid = luid = euid would be the norm.

Thus the Linux one happens to be a uid_t. It could be something else but for the "container per user" model whatever a container is must be able to hold all possible uid_t values. So we can certainly do something like

Quoted 1 line

typedef uid_t container_id_t;

What about cid_t? Google mentions cid_t was used in HP-UX specific IPC (only if _INCLUDE_HPUX_SOURCE is defined).

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +10 -0

+{
+	int error;
+	unsigned long flags;
+	struct beancounter *bc;
+	unsigned long new_limits[2];
+
+	error = -EPERM;
+	if(!capable(CAP_SYS_RESOURCE))
+		goto out;
+

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +23 -0

+{
+	int error;
+	unsigned long flags;
+	struct beancounter *bc;
+	struct bc_resource_parm parm;
+
+	error = -EINVAL;
+	if (resource > BC_RESOURCES)
+		goto out;
+
+	error = -ENOENT;
+	bc = beancounter_findcreate(id, 0);
+	if (bc == NULL)
+		goto out;
+
+	spin_lock_irqsave(&bc->bc_lock, flags);
+	parm = bc->bc_parms[resource];
+	spin_unlock_irqrestore(&bc->bc_lock, flags);
+	put_beancounter(bc);
+
+	error = 0;
+	if (copy_to_user(uparm, &parm, sizeof(parm)))
+		error = -EFAULT;

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +22 -0

+asmlinkage long sys_set_bclimit(uid_t id, unsigned long resource,
+		unsigned long *limits)
+{
+	int error;
+	unsigned long flags;
+	struct beancounter *bc;
+	unsigned long new_limits[2];
+
+	error = -EPERM;
+	if(!capable(CAP_SYS_RESOURCE))
+		goto out;
+
+	error = -EINVAL;
+	if (resource >= BC_RESOURCES)
+		goto out;
+
+	error = -EFAULT;
+	if (copy_from_user(&new_limits, limits, sizeof(new_limits)))
+		goto out;
+
+	error = -EINVAL;
+	if (new_limits[0] > BC_MAXVALUE || new_limits[1] > BC_MAXVALUE)

kernel/bc/sys.c renamed from kernel/bc/sys.c.ve3 +7 -0

+	spin_unlock_irqrestore(&bc->bc_lock, flags);
+
+	put_beancounter(bc);
+	error = 0;
+out:
+	return error;
+}

include/bc/beancounter.h renamed from include/bc/beancounter.h.bckmem +0 -0

 struct resource_parm {
 	/*

include/bc/kmem.h renamed from include/bc/kmem.h.bckmem +33 -0

@@ -0,0 +1,33 @@
+/*
+ *  include/bc/kmem.h
+ *
+ *  Copyright (C) 2006 OpenVZ. SWsoft Inc
+ *
+ */
+
+#ifndef __BC_KMEM_H_
+#define __BC_KMEM_H_
+
+#include <linux/config.h>
+
+/*
+ * BC_KMEMSIZE accounting
+ */
+
+struct mm_struct;
+struct page;
+struct beancounter;
+
+#ifdef CONFIG_BEANCOUNTERS
+int  bc_page_charge(struct page *page, int order, gfp_t flags);
+void bc_page_uncharge(struct page *page, int order);
+
+int bc_slab_charge(kmem_cache_t *cachep, void *obj, gfp_t flags);
+void bc_slab_uncharge(kmem_cache_t *cachep, void *obj);
+#else
+#define bc_page_charge(pg, o, mask)	(0)
+#define bc_page_uncharge(pg, o)		do { } while (0)
+#define bc_slab_charge(cachep, o, f)	(0)
+#define bc_slab_uncharge(cachep, o)	do { } while (0)
+#endif
+#endif /* __BC_SLAB_H_ */

kernel/bc/Makefile renamed from kernel/bc/Makefile.bcsys +1 -0

@@ -7,3 +7,4 @@
 obj-$(CONFIG_BEANCOUNTERS) += beancounter.o
 obj-$(CONFIG_BEANCOUNTERS) += misc.o
 obj-$(CONFIG_BEANCOUNTERS) += sys.o
+obj-$(CONFIG_BEANCOUNTERS) += kmem.o

kernel/bc/beancounter.c renamed from kernel/bc/beancounter.c.bckmem +0 -0

 	for (k = 0; k < BC_RESOURCES; k++)
 		bc->bc_parms[k].barrier = bc->bc_parms[k].limit;
 }

kernel/bc/kmem.c line 28

Quoted 8 lines · Kirill Korotaev

kernel/bc/kmem.c renamed from kernel/bc/kmem.c.bckmem +8 -0

+int bc_slab_charge(kmem_cache_t *cachep, void *objp, gfp_t flags)
+{
+	unsigned int size;
+	struct beancounter *bc, **slab_bcp;
+
+	bc = get_exec_bc();
+	if (bc == NULL)
+		return 0;

Is it possible to .exec_bc == NULL ?

If yes, why do we need init_bc? We can do 'set_exec_bc(NULL)' in __do_IRQ() instead.