[PATCH] memparse bugfix
Function lib/cmdline.c:memparse() wrongly calculates the memory if the given string has K/M/G suffix. This patch (against 2.6.13-rc3) fixes the problem. Please apply. Signed-off-by: Nguyen Anh Quynh <[EMAIL PROTECTED]> # diffstat cmdline.patch cmdline-aq.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) cmdline.patch Description: Binary data
Re: [PATCH] memparse bugfix
On 7/16/05, Chris Wright <[EMAIL PROTECTED]> wrote:
> * aq ([EMAIL PROTECTED]) wrote:
> > Function lib/cmdline.c:memparse() wrongly calculates the memory if the
> > given string has K/M/G suffix. This patch (against 2.6.13-rc3) fixes
> > the problem. Please apply.
>
> Patch looks incorrect.
>
> > --- 2.6.13-rc3/lib/cmdline.c 2005-04-30 10:31:37.0 +0900
> > +++ 2.6.13-rc3/lib/cmdline-aq.c 2005-07-16 02:25:26.0 +0900
> > @@ -100,10 +100,10 @@ unsigned long long memparse (char *ptr,
> > switch (**retptr) {
> > case 'G':
> > case 'g':
> > - ret <<= 10;
> > + ret <<= 30;
> > case 'M':
> > case 'm':
> > - ret <<= 10;
> > + ret <<= 20;
> > case 'K':
> > case 'k':
> > ret <<= 10;
>
> Now, G == ret << 80, M == ret << 30... Notice the fall-thru cases.
>
oops, this code doesnt use "break" like normally. what a trap!
sorry for the noise :-)
regards,
aq
-
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/
[PATCH] dontdiff file sorted in alphabet order
hello, The Documentation/dontdiffI file of 2.6.12-rc3 kernel is a little messy. Here is a patch to sort the content of that file in alphabet order. Please apply. # diffstat dontdiff.patch dontdiff | 136 +++ 1 files changed, 68 insertions(+), 68 deletions(-) Signed-off-by: Nguyen Anh Quynh <[EMAIL PROTECTED]> dontdiff.patch Description: Binary data
Re: forkbombing Linux distributions
On Tue, 22 Mar 2005 07:50:25 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 22, 2005 at 12:49:58PM +0100, Jan Engelhardt wrote:
> > >
> > >This will prevent it from exceeding the procs limits, but it will *not*
> > >completely stop it.
> >
> > What if the few procs that he may spawn also grab so much memory so your
> > machine disappears in swap-t(h)rashing?
> While I have figured out how it'd be possible in theory to prevent things
> from grabbing so much memory that your computer enters swap death, I haven't
> been able to figure out what reasonable defaults would be for myself or
> others. S, I suggest everyone who is worried about this check the
> manpage for 'limits' which tells you how to do this. My machine runs various
> rediculously large and small programs - I'm not sure a forkbomb could be
> stopped without hindering the usage of some of the games on my desktop
> machine.
>
> On a server or something with multiple users however, I'm sure you could
> configure each user independently with resource limits. Most servers
> don't have users that play games which take up 90% of the ram. :)
>
> In any case, I was forced by various smarter-than-I people to come up with a
> better solution to our problem as they were able to make forkbombs that did
> a much better job of driving me crazy. :)
>
> If you edit or create /etc/limits and set as the only line
>
> * U250
>
> It'll do the same thing as the sysctl hack, except root will still be able
> to run programs. Programs like ps and kill/killall.
>
> If you've actually implemented the sysctl.conf hack I spoke of previously, I
> suggest setting it back to whatever it used to be before, or deleting the
> line from /etc/sysctl.conf altogether.
>
> /etc/limits does a better job at stopping forkbombs.
>
> This is an example of a program in C my friends gave me that forkbombs.
> My previous sysctl.conf hack can't stop this, but the /etc/limits solution
> enables the owner of the computer to do something about it as root.
>
> int main() { while(1) { fork(); } }
>
I find that this forkbomb doesnt always kill the machine. Trying a
small forkbomb, I saw that either the forkbomb process, or the parent
process (of forkbomb) will be killed after a while (by the kernel)
because of "out of memory" error. The problem is that which process
would be chosen to kill? (I have no idea on how kernel choose the
would-be-kill process).
If the kernel choose to kill the parent process, or the forkbomb
itself, damage can be afford. Otherwise, if the more important
processes are killed (like kernel threads or other daemons), things
would be much more serious.
Any idea?
Thank you,
aq
-
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/
Re: forkbombing Linux distributions
On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > This is an example of a program in C my friends gave me that forkbombs.
> > > My previous sysctl.conf hack can't stop this, but the /etc/limits solution
> > > enables the owner of the computer to do something about it as root.
> > >
> > > int main() { while(1) { fork(); } }
>
> I guess that "fork twice and exit" is worse than this?
you meant code like this
int main() { while(1) { fork(); fork(); exit(); } }
is more harmful ? I dont see why (?)
> > I find that this forkbomb doesnt always kill the machine. Trying a
> > small forkbomb, I saw that either the forkbomb process, or the parent
> > process (of forkbomb) will be killed after a while (by the kernel)
> > because of "out of memory" error. The problem is that which process
> > would be chosen to kill? (I have no idea on how kernel choose the
> > would-be-kill process).
>
> It kills the process that reaches the limit (max proc's / out of mem)?
If so, forkbomb doesnt cause much problem like they said, since
eventually it would be killed once it reach the limit of memory. the
system will recover automatically after awhile.
> Limit the default maximum of user processes. If someone needs more, let
> the sysadmin raise it (with ulimit -u, /etc/limits, sysctl.conf
> whatever)
>
> This should do the trick:
>
> --- kernel/fork.c.orig 2005-03-02 08:37:48.0 +0100
> +++ kernel/fork.c 2005-03-21 15:22:50.0 +0100
> @@ -119,7 +119,7 @@
> * value: the thread structures can take up at most half
> * of memory.
> */
> - max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> + max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
I dont see any advantages of halving the max_threads like this at all.
That doesnt solve the problem. You should focus elsewhere.
thank you,
aq
-
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/
Re: forkbombing Linux distributions
On Wed, 23 Mar 2005 14:54:18 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-23 at 22:04 +0900, aq wrote:
> > On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > > > This is an example of a program in C my friends gave me that
> > > > > forkbombs.
> > > > > My previous sysctl.conf hack can't stop this, but the /etc/limits
> > > > > solution
> > > > > enables the owner of the computer to do something about it as root.
> > > > >
> > > > > int main() { while(1) { fork(); } }
> > >
> > > I guess that "fork twice and exit" is worse than this?
> >
> > you meant code like this
> >
> > int main() { while(1) { fork(); fork(); exit(); } }
> >
> > is more harmful ? I dont see why (?)
>
> Because the parent disappears. When things like killall tries to kill
> the process its already gone but there are 2 new with new pids.
>
are you sure? the above forkbomb will stop quickly after just several
spawns because of exit().
I agree that make kernel more restrictive by default is a good approach.
thank you,
aq
-
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/
Re: forkbombing Linux distributions
On Wed, 23 Mar 2005 10:05:43 -0800, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > int main() { while(1) { fork(); fork(); exit(); } }
> > ...
> > the above forkbomb will stop quickly
>
> Yep.
>
> Try this forkbomb:
>
> int main() { while(1) { if (!fork()) continue; if (!fork()) continue;
> exit(); } }
>
yep, that is better. but system can still be recovered by killall.
a little "sleep" will render the system completely useless, like this:
int main() { while(1) { if (!fork()) continue; if (!fork()) continue;
sleep(5); exit(0); } }
thank you,
aq
-
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/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
arent and
> + its child. This information can be used by a user space application.
> + The fork connector can be enable/disable by sending a message to the
> + connector with the corresponding group id.
> +
> endmenu
> diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/include/linux/connector.h
> linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h
> --- linux-2.6.11-rc4-mm1/include/linux/connector.h 2005-02-23
> 11:12:17.0 +0100
> +++ linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h 2005-02-24
> 10:25:22.0 +0100
> @@ -28,6 +28,8 @@
> #define CN_VAL_KOBJECT_UEVENT 0x
> #define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
> #define CN_VAL_SUPERIO 0xccdd
> +#define CN_IDX_FORK0xfeed /* fork events */
> +#define CN_VAL_FORK0xbeef
>
> #define CONNECTOR_MAX_MSG_SIZE 1024
> @@ -133,6 +135,7 @@ struct cn_dev
> };
>
> extern int cn_already_initialized;
> +extern int cn_fork_enable;
>
> int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
> void cn_del_callback(struct cb_id *);
> diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/kernel/fork.c
> linux-2.6.11-rc4-mm1-cnfork/kernel/fork.c
> --- linux-2.6.11-rc4-mm1/kernel/fork.c 2005-02-23 11:12:17.0 +0100
> +++ linux-2.6.11-rc4-mm1-cnfork/kernel/fork.c 2005-02-24 10:27:02.0
> +0100
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -63,6 +64,48 @@ DEFINE_PER_CPU(unsigned long, process_co
>
> EXPORT_SYMBOL(tasklist_lock);
>
> +#ifdef CONFIG_FORK_CONNECTOR
> +
> +#define CN_FORK_INFO_SIZE 64
> +#define CN_FORK_MSG_SIZE sizeof(struct cn_msg) + CN_FORK_INFO_SIZE
> +
> +spinlock_t fork_cn_lock = SPIN_LOCK_UNLOCKED;
> +
> +static inline void fork_connector(pid_t parent, pid_t child)
> +{
> + static const struct cb_id fork_id = { CN_IDX_FORK, CN_VAL_FORK };
> + static __u32 seq; /* used to test if message is lost */
> +
> + if (cn_fork_enable) {
> + struct cn_msg *msg;
> + __u8 buffer[CN_FORK_MSG_SIZE];
> +
> + msg = (struct cn_msg *)buffer;
> +
> + memcpy(&msg->id, &fork_id, sizeof(msg->id));
> + spin_lock(&fork_cn_lock);
> + msg->seq = seq++;
> + spin_unlock(&fork_cn_lock);
> + msg->ack = 0; /* not used */
> + /*
> +* size of data is the number of characters
> +* printed plus one for the trailing '\0'
> +*/
> + /* just fill the data part with '\0' */
> + memset(msg->data, '\0', CN_FORK_INFO_SIZE);
> + msg->len = scnprintf(msg->data, CN_FORK_INFO_SIZE-1,
> + "%i %i", parent, child) + 1;
> +
> + cn_netlink_send(msg, CN_IDX_FORK);
> + }
> +}
> +#else
> +static inline void fork_connector(pid_t parent, pid_t child)
> +{
> + return;
> +}
> +#endif
> +
> int nr_processes(void)
> {
> int cpu;
> @@ -1238,6 +1281,8 @@ long do_fork(unsigned long clone_flags,
> if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
> ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8)
> | SIGTRAP);
> }
> +
> + fork_connector(current->pid, p->pid);
> } else {
> free_pidmap(pid);
> pid = PTR_ERR(p);
Guillaume, I see that you are trying to discover if the kernel has
CONFIG_FORK_CONNECTOR defined or not. In case CONFIG_FORK_CONNECTOR is
not defined, you will call a "dummy" fork_connector (which just call
"return"). But why you dont move the checking to where you call
fork_connector? In this case, if CONFIG_FORK_CONNECTOR is not defined,
nothing called, and of course you dont need a "dummy" fork_connector
like in the above code.
Just try something like this:
+#ifdef CONFIG_FORK_CONNECTOR
+
+ fork_connector(current->pid, p->pid);
#endif
regards,
AQ
-
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/
