[PATCH 1/6] drivers/media/dvb-core/en50221: move code to dvb_ca_private_free()

Prepare for postponing the call until all file handles have been closed. Signed-off-by: Max Kellermann --- drivers/media/dvb-core/dvb_ca_en50221.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb

[PATCH 3/6] drivers/media/media-devnode: clear private_data before put_device()

Callbacks invoked from put_device() may free the struct media_devnode pointer, so any cleanup needs to be done before put_device(). Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/media-devnode.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/d

[PATCH 4/6] drivers/media/media-device: move debug log before _devnode_unregister()

After media_devnode_unregister(), the struct media_device may be freed already, and dereferencing it may crash. Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/media-device.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/media-de

[PATCH 3/6] drivers/media/media-devnode: clear private_data before put_device()

Callbacks invoked from put_device() may free the struct media_devnode pointer, so any cleanup needs to be done before put_device(). Signed-off-by: Max Kellermann --- drivers/media/media-devnode.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/media

[PATCH 4/6] drivers/media/media-device: move debug log before _devnode_unregister()

After media_devnode_unregister(), the struct media_device may be freed already, and dereferencing it may crash. Signed-off-by: Max Kellermann --- drivers/media/media-device.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/media-device.c b/drivers/media

[PATCH 2/6] drivers/media/dvb-core/en50221: postpone release until file is closed

Fixes use-after-free bug which occurs when I disconnect my DVB-S received while VDR is running. Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/dvb-core/dvb_ca_en50221.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers

[PATCH 2/6] drivers/media/dvb-core/en50221: postpone release until file is closed

Fixes use-after-free bug which occurs when I disconnect my DVB-S received while VDR is running. Signed-off-by: Max Kellermann --- drivers/media/dvb-core/dvb_ca_en50221.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

All accesses to media_devnode_nums must be protected with media_devnode_lock. The error code path in media_devnode_register() did not do this, however. Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

All accesses to media_devnode_nums must be protected with media_devnode_lock. The error code path in media_devnode_register() did not do this, however. Signed-off-by: Max Kellermann --- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/media

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index cea35bf..4d7e8dd 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

Signed-off-by: Max Kellermann --- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index cea35bf..4d7e8dd 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media/media-devnode.c @@ -266,8

[PATCH] drivers/media/rc: postpone kfree(rc_dev)

CONFIG_DEBUG_KOBJECT_RELEASE found this bug. Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/rc/rc-main.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 1042fa3..cb3e8db

[PATCH] drivers/media/rc: postpone kfree(rc_dev)

CONFIG_DEBUG_KOBJECT_RELEASE found this bug. Signed-off-by: Max Kellermann --- drivers/media/rc/rc-main.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 1042fa3..cb3e8db 100644 --- a/drivers/media/rc/rc

Re: [PATCH] drivers/media/rc: postpone kfree(rc_dev)

On 2016/03/21 13:24, Mauro Carvalho Chehab wrote: > Please, always send us your Signed-off-by on your patches, as described at: > > https://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 Sorry, I forgot this, and

Re: [PATCH] drivers/media/rc: postpone kfree(rc_dev)

On 2016/03/21 13:24, Mauro Carvalho Chehab wrote: > Please, always send us your Signed-off-by on your patches, as described at: > > https://linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 Sorry, I forgot this, and remembered only right

[PATCH] drivers/media/rc: postpone kfree(rc_dev)

CONFIG_DEBUG_KOBJECT_RELEASE found this bug. --- drivers/media/rc/rc-main.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 1042fa3..cb3e8db 100644 --- a/drivers/media/rc/rc-main.c +++

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

--- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index cea35bf..4d7e8dd 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media/media-devnode.c @@ -266,8 +266,11 @@ int __must_check

[PATCH] drivers/media/media-devnode: add missing mutex lock in error handler

--- drivers/media/media-devnode.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index cea35bf..4d7e8dd 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media/media-devnode.c @@ -266,8 +266,11 @@ int __must_check

[PATCH] drivers/media/rc: postpone kfree(rc_dev)

CONFIG_DEBUG_KOBJECT_RELEASE found this bug. --- drivers/media/rc/rc-main.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 1042fa3..cb3e8db 100644 --- a/drivers/media/rc/rc-main.c +++

[PATCH 2/2] media/dvb-core: forward media_create_pad_links() return value

Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/dvb-core/dvbdev.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c index c756d4b..96de2fa 100644 --- a/drivers/media/dvb-core/dv

[PATCH 2/2] media/dvb-core: forward media_create_pad_links() return value

Signed-off-by: Max Kellermann --- drivers/media/dvb-core/dvbdev.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c index c756d4b..96de2fa 100644 --- a/drivers/media/dvb-core/dvbdev.c +++ b/drivers/media

[PATCH 1/2] media/dvb-core: fix inverted check

Breakage caused by commit f50d51661a Signed-off-by: Max Kellermann <m...@duempel.org> --- drivers/media/dvb-core/dvbdev.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c index 560450a..c756d4b

[PATCH 1/2] media/dvb-core: fix inverted check

Breakage caused by commit f50d51661a Signed-off-by: Max Kellermann --- drivers/media/dvb-core/dvbdev.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c index 560450a..c756d4b 100644 --- a/drivers/media/dvb

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 18:29, Tejun Heo wrote: > It's not a stateful resource. Of course the resource is controlled in > terms of bandwidth not absoulte amount consumed. I'm glad we now agree on the basic facts. > It's absurd to limit absoulte amount for CPU cycles. And yet there's an "absurd" feature

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:44, Tejun Heo wrote: > On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote: > > There's "cpu" which changes priority > > The cpu controller can limit both in terms of relative weight and > absolute CPU cycle bandwidth. No, Tejun, the "

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:25, Aleksa Sarai wrote: > > The goal of this limit is to have another safeguard against fork > > bombs. It gives processes a chance to set up their child processes / > > threads, but will be stopped once they attempt to waste resources by > > continuously exiting and cloning new

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:12, Tejun Heo wrote: > On Tue, Nov 10, 2015 at 03:06:46PM +0100, Max Kellermann wrote: > > This patch introduces a new setting called "fork_remaining". When > > positive, each successful fork decrements the value, and once it > > reaches zero

[PATCH] cgroup_pids: add fork limit

e new "pids" controller, which implements a similar idea. Signed-off-by: Max Kellermann --- Documentation/cgroups/pids.txt | 31 ++ kernel/cgroup_pids.c | 123 2 files changed, 153 insertions(+), 1 deletion(-) diff --git a/Docume

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:12, Tejun Heo <t...@kernel.org> wrote: > On Tue, Nov 10, 2015 at 03:06:46PM +0100, Max Kellermann wrote: > > This patch introduces a new setting called "fork_remaining". When > > positive, each successful fork decrements the value, and once it >

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:25, Aleksa Sarai wrote: > > The goal of this limit is to have another safeguard against fork > > bombs. It gives processes a chance to set up their child processes / > > threads, but will be stopped once they attempt to waste resources by > > continuously

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:44, Tejun Heo <t...@kernel.org> wrote: > On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote: > > There's "cpu" which changes priority > > The cpu controller can limit both in terms of relative weight and > absolute CPU cycle bandwidth

Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 18:29, Tejun Heo wrote: > It's not a stateful resource. Of course the resource is controlled in > terms of bandwidth not absoulte amount consumed. I'm glad we now agree on the basic facts. > It's absurd to limit absoulte amount for CPU cycles. And yet there's an

[PATCH] cgroup_pids: add fork limit

e new "pids" controller, which implements a similar idea. Signed-off-by: Max Kellermann <m...@cm4all.com> --- Documentation/cgroups/pids.txt | 31 ++ kernel/cgroup_pids.c | 123 2 files changed, 153 insertions(+), 1 deletion(-)

Re: [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

On 2014/03/19 22:22, Max Kellermann wrote: > + list_add(>mnt_unmounted, >mnt_hash); This is obviously a bug in my patch, sorry. Will resend a fixed patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

[PATCH] fs/namespace: don't clobber mnt_hash.next while umounting [v2]

il namespace_unlock() is called. This regression was caused by commit 48a066e7 ("RCU'd vfsmounts"). All releases since 3.12-rc5 are affected. Signed-off-by: Max Kellermann --- fs/mount.h |1 + fs/namespace.c | 12 +++- fs/pnode.c |8 +--- 3 files changed, 13 ins

Re: [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

On 2014/03/19 22:22, Max Kellermann wrote: > In the presence of user+mount namespaces, this bug can be exploited by > any unprivileged user to stall the kernel (denial of service by soft > lockup). Proof-of-concept exploit attached. /* * Exploit for lin

[PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

il namespace_unlock() is called. This regression was caused by commit 48a066e7 ("RCU'd vfsmounts"). All releases since 3.12-rc5 are affected. Signed-off-by: Max Kellermann --- fs/mount.h |1 + fs/namespace.c | 12 +++- fs/pnode.c |8 +--- 3 files changed, 13 ins

[PATCH 2/2] fs/namespace: use RCU list functions for mnt_hash

mount.mnt_hash is RCU-protected, and therefore we must use the RCU variants to manipulate the list. Signed-off-by: Max Kellermann --- fs/namespace.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 2aa0a14..295a0c0 100644

[PATCH 2/2] fs/namespace: use RCU list functions for mnt_hash

mount.mnt_hash is RCU-protected, and therefore we must use the RCU variants to manipulate the list. Signed-off-by: Max Kellermann m...@cm4all.com --- fs/namespace.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 2aa0a14

[PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

(RCU'd vfsmounts). All releases since 3.12-rc5 are affected. Signed-off-by: Max Kellermann m...@cm4all.com --- fs/mount.h |1 + fs/namespace.c | 12 +++- fs/pnode.c |8 +--- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/fs/mount.h b/fs/mount.h index

Re: [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

On 2014/03/19 22:22, Max Kellermann m...@cm4all.com wrote: In the presence of user+mount namespaces, this bug can be exploited by any unprivileged user to stall the kernel (denial of service by soft lockup). Proof-of-concept exploit attached. /* * Exploit for linux commit

[PATCH] fs/namespace: don't clobber mnt_hash.next while umounting [v2]

(RCU'd vfsmounts). All releases since 3.12-rc5 are affected. Signed-off-by: Max Kellermann m...@cm4all.com --- fs/mount.h |1 + fs/namespace.c | 12 +++- fs/pnode.c |8 +--- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/fs/mount.h b/fs/mount.h index

Re: [PATCH 1/2] fs/namespace: don't clobber mnt_hash.next while umounting

On 2014/03/19 22:22, Max Kellermann m...@cm4all.com wrote: + list_add(child-mnt_unmounted, mnt-mnt_hash); This is obviously a bug in my patch, sorry. Will resend a fixed patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

[PATCH] fscache: extended "dying" check before emitting EV_INVALIDATE

ueued. The solution is to check for EV_RETIRE and EV_RELEASE; if one of those two terminal events is already queued, don't bother to queue EV_INVALIDATE. Signed-off-by: Max Kellermann --- fs/fscache/cookie.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/fscache/cookie.

[PATCH] fscache: extended dying check before emitting EV_INVALIDATE

; if one of those two terminal events is already queued, don't bother to queue EV_INVALIDATE. Signed-off-by: Max Kellermann m...@cm4all.com --- fs/fscache/cookie.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c index 8dcb114..ed80d7f

Re: 2.6.23.1: oops in diskstats_show()

On 2008/01/29 23:22, Rick Lindsley <[EMAIL PROTECTED]> wrote: > Right before the crash, I was torturing cryptsetup to experiment with > encryption - I created and deleted device mapper objects in a loop. > > Creating and deleting block devices ... yeah, this is probably key to > the

Re: 2.6.23.1: oops in diskstats_show()

On 2008/01/29 23:22, Rick Lindsley [EMAIL PROTECTED] wrote: Right before the crash, I was torturing cryptsetup to experiment with encryption - I created and deleted device mapper objects in a loop. Creating and deleting block devices ... yeah, this is probably key to the problem. Can

2.6.23.1: oops in diskstats_show()

Hi, my kernel 2.6.23.1 oopsed today in diskstats_show(), leaving the block_subsys_lock mutex locked. I have an Athlon 64 X2 (dual-core), architecture x86_64. I have not tried with 2.6.24 yet, but it looks like there was no relevant change in 2.6.24. Right before the crash, I was torturing

Re: [PATCH] /proc Security Hooks

On 2007/10/16 21:54, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Tue, 16 Oct 2007 21:38:50 +0200 > Max Kellermann <[EMAIL PROTECTED]> wrote: > > This patch attempts to unify duplicated code found in modules like > > Linux VServer. > > can you please merge

[PATCH] /proc Security Hooks

in modules like Linux VServer. Signed-off-by: Max Kellermann <[EMAIL PROTECTED]> --- fs/proc/base.c |9 + fs/proc/generic.c| 15 +++ include/linux/security.h | 46 ++ security/Kconfig |8 ++

[PATCH] /proc Security Hooks

Linux VServer. Signed-off-by: Max Kellermann [EMAIL PROTECTED] --- fs/proc/base.c |9 + fs/proc/generic.c| 15 +++ include/linux/security.h | 46 ++ security/Kconfig |8 security

Re: [PATCH] /proc Security Hooks

On 2007/10/16 21:54, Arjan van de Ven [EMAIL PROTECTED] wrote: On Tue, 16 Oct 2007 21:38:50 +0200 Max Kellermann [EMAIL PROTECTED] wrote: This patch attempts to unify duplicated code found in modules like Linux VServer. can you please merge this patch only when you also merge the first

Re: [PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

On 2007/04/18 09:56, Tejun Heo <[EMAIL PROTECTED]> wrote: > It's more likely your chipset just has busted MSI support. Please > post the result of 'lspci -tv' and 'lspci -nn'. See attachments. I found the "nomsi" workaround in a forum, and didn't bother to investigate the real cause yet. Max

Re: [PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

On 2007/04/18 08:26, Tejun Heo <[EMAIL PROTECTED]> wrote: > Can you try it on another controller? Say, a ahci or sil24? Seems to work ok on a Via VT8251 controller (AHCI) on kernel 2.6.21-rc6-git4 without my NCQ disabling patch. By the way, on this machine, I had a lot of SATA timeouts during

[PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

ata1.00: exception Emask 0x0 SAct 0x3fff SErr 0x20 action 0x2 frozen [...] ata1: soft resetting port http://lkml.org/lkml/2007/3/16/184 Signed-off-by: Max Kellermann <[EMAIL PROTECTED]> drivers/ata/libata-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/d

[PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

ata1.00: exception Emask 0x0 SAct 0x3fff SErr 0x20 action 0x2 frozen [...] ata1: soft resetting port http://lkml.org/lkml/2007/3/16/184 Signed-off-by: Max Kellermann [EMAIL PROTECTED] drivers/ata/libata-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/ata

Re: [PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote: Can you try it on another controller? Say, a ahci or sil24? Seems to work ok on a Via VT8251 controller (AHCI) on kernel 2.6.21-rc6-git4 without my NCQ disabling patch. By the way, on this machine, I had a lot of SATA timeouts during

Re: [PATCH] libata: add Samsung HD401LJ to the NCQ blacklist

On 2007/04/18 09:56, Tejun Heo [EMAIL PROTECTED] wrote: It's more likely your chipset just has busted MSI support. Please post the result of 'lspci -tv' and 'lspci -nn'. See attachments. I found the nomsi workaround in a forum, and didn't bother to investigate the real cause yet. Max

Re: [BUG 2.6.21-rc3-git9] SATA NCQ failure with Samsum HD401LJ

On 2007/03/19 13:09, Jeff Garzik <[EMAIL PROTECTED]> wrote: > I may have missed the answer to this before, but: does the problem > go away if you disable preempt? On my system (same problem, original bug report), preemption is disabled. Max - To unsubscribe from this list: send the line

Re: [BUG 2.6.21-rc3-git9] SATA NCQ failure with Samsum HD401LJ

On 2007/03/19 13:09, Jeff Garzik [EMAIL PROTECTED] wrote: I may have missed the answer to this before, but: does the problem go away if you disable preempt? On my system (same problem, original bug report), preemption is disabled. Max - To unsubscribe from this list: send the line unsubscribe

[PATCH] print unsigned integers in sunrpc stats

Hi, the sunrpc stats are collected in unsigned integers, but they are printed with '%d'. That can result in negative numbers in /proc/net/rpc when the highest bit of a counter is set. The following patch changes '%d' to '%u' where appropriate. Max --- linux-2.6.13/net/sunrpc/stats.c.orig

[PATCH] print unsigned integers in sunrpc stats

Hi, the sunrpc stats are collected in unsigned integers, but they are printed with '%d'. That can result in negative numbers in /proc/net/rpc when the highest bit of a counter is set. The following patch changes '%d' to '%u' where appropriate. Max --- linux-2.6.13/net/sunrpc/stats.c.orig

Re: forkbombing Linux distributions

On 2005/03/23 15:44, Natanael Copa <[EMAIL PROTECTED]> wrote: > Yes, but if > RLIMIT_NPROC is per user and RLIMIT_CPU is per proc > > the theoretical CPU limit per user is RLIMIT_NPROC * RLIMIT_CPU. So if > you half the RLIMIT_NPROC you will half the theoretical maximum CPU > limit per user. >

Re: forkbombing Linux distributions

On 2005/03/23 15:23, Natanael Copa <[EMAIL PROTECTED]> wrote: > On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote: > > The number of processes is counted per user, but CPU time and memory > > consumption is counted per process. > > So limiting maximum number of p

Re: forkbombing Linux distributions

On 2005/03/22 12:49, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > What if the few procs that he may spawn also grab so much memory so > your machine disappears in swap-t(h)rashing? The number of processes is counted per user, but CPU time and memory consumption is counted per process. Going

Re: forkbombing Linux distributions

On 2005/03/22 12:49, Jan Engelhardt [EMAIL PROTECTED] wrote: What if the few procs that he may spawn also grab so much memory so your machine disappears in swap-t(h)rashing? The number of processes is counted per user, but CPU time and memory consumption is counted per process. Going around

Re: forkbombing Linux distributions

On 2005/03/23 15:23, Natanael Copa [EMAIL PROTECTED] wrote: On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote: The number of processes is counted per user, but CPU time and memory consumption is counted per process. So limiting maximum number of processes will automatically limit CPU

Re: forkbombing Linux distributions

On 2005/03/23 15:44, Natanael Copa [EMAIL PROTECTED] wrote: Yes, but if RLIMIT_NPROC is per user and RLIMIT_CPU is per proc the theoretical CPU limit per user is RLIMIT_NPROC * RLIMIT_CPU. So if you half the RLIMIT_NPROC you will half the theoretical maximum CPU limit per user. Same

Re: Netfilter: TARPIT Target

On 2005/02/17 15:41, "Fao, Sean" <[EMAIL PROTECTED]> wrote: > I wanted to use the TARPIT target provided by Netfilter, but I am unable > to find the module in the kernel. Has it been removed or am I looking > in the wrong place? It is not in the mainstream kernel yet. You can find it in

Re: Netfilter: TARPIT Target

On 2005/02/17 15:41, Fao, Sean [EMAIL PROTECTED] wrote: I wanted to use the TARPIT target provided by Netfilter, but I am unable to find the module in the kernel. Has it been removed or am I looking in the wrong place? It is not in the mainstream kernel yet. You can find it in netfilter

<    1   2