Re: [PATCH] swsusp: Use platform mode by default
Hello,
(This patch is merged in 2.6.20 as commit
9185cfa92507d07ac787bc73d06c4eec7239)
With this patch, my desktop no longer powers off after hibernate(8).
It just reboots.
This user land fix can restore the old behavior:
echo shutdown > /sys/power/disk
The commit causes user land breakage. Is this behavior on purpose?
thanks,
Qi
On 02/11/06, Len Brown <[EMAIL PROTECTED]> wrote:
Applied.
thanks,
-Len
On Wednesday 01 November 2006 07:23, Rafael J. Wysocki wrote:
> It has been reported that on some systems the functionality after a resume
> from disk is limited if the system is simply powered off during the suspend
> instead of using the ACPI S4 suspend (aka platform mode).
>
> Unfortunately the default is currently to power off the system during the
> suspend so the users of these systems experience problems after the resume
> if they don't switch to the platform mode explicitly. This patch makes swsusp
> use the platform mode by default to avoid such situations.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> kernel/power/disk.c |8 +---
> kernel/power/main.c |2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.19-rc4-mm1/kernel/power/main.c
> ===
> --- linux-2.6.19-rc4-mm1.orig/kernel/power/main.c
> +++ linux-2.6.19-rc4-mm1/kernel/power/main.c
> @@ -29,7 +29,7 @@
> DECLARE_MUTEX(pm_sem);
>
> struct pm_ops *pm_ops;
> -suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;
> +suspend_disk_method_t pm_disk_mode = PM_DISK_PLATFORM;
>
> /**
> * pm_set_ops - Set the global power method table.
> Index: linux-2.6.19-rc4-mm1/kernel/power/disk.c
> ===
> --- linux-2.6.19-rc4-mm1.orig/kernel/power/disk.c
> +++ linux-2.6.19-rc4-mm1/kernel/power/disk.c
> @@ -62,9 +62,11 @@ static void power_down(suspend_disk_meth
>
> switch(mode) {
> case PM_DISK_PLATFORM:
> - kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
> - error = pm_ops->enter(PM_SUSPEND_DISK);
> - break;
> + if (pm_ops && pm_ops->enter) {
> + kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
> + error = pm_ops->enter(PM_SUSPEND_DISK);
> + break;
> + }
> case PM_DISK_SHUTDOWN:
> kernel_power_off();
> break;
> -
--
Qi Yong
-
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] swsusp: Use platform mode by default
Hello,
(This patch is merged in 2.6.20 as commit
9185cfa92507d07ac787bc73d06c4eec7239)
With this patch, my desktop no longer powers off after hibernate(8).
It just reboots.
This user land fix can restore the old behavior:
echo shutdown /sys/power/disk
The commit causes user land breakage. Is this behavior on purpose?
thanks,
Qi
On 02/11/06, Len Brown [EMAIL PROTECTED] wrote:
Applied.
thanks,
-Len
On Wednesday 01 November 2006 07:23, Rafael J. Wysocki wrote:
It has been reported that on some systems the functionality after a resume
from disk is limited if the system is simply powered off during the suspend
instead of using the ACPI S4 suspend (aka platform mode).
Unfortunately the default is currently to power off the system during the
suspend so the users of these systems experience problems after the resume
if they don't switch to the platform mode explicitly. This patch makes swsusp
use the platform mode by default to avoid such situations.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/power/disk.c |8 +---
kernel/power/main.c |2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.19-rc4-mm1/kernel/power/main.c
===
--- linux-2.6.19-rc4-mm1.orig/kernel/power/main.c
+++ linux-2.6.19-rc4-mm1/kernel/power/main.c
@@ -29,7 +29,7 @@
DECLARE_MUTEX(pm_sem);
struct pm_ops *pm_ops;
-suspend_disk_method_t pm_disk_mode = PM_DISK_SHUTDOWN;
+suspend_disk_method_t pm_disk_mode = PM_DISK_PLATFORM;
/**
* pm_set_ops - Set the global power method table.
Index: linux-2.6.19-rc4-mm1/kernel/power/disk.c
===
--- linux-2.6.19-rc4-mm1.orig/kernel/power/disk.c
+++ linux-2.6.19-rc4-mm1/kernel/power/disk.c
@@ -62,9 +62,11 @@ static void power_down(suspend_disk_meth
switch(mode) {
case PM_DISK_PLATFORM:
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
- error = pm_ops-enter(PM_SUSPEND_DISK);
- break;
+ if (pm_ops pm_ops-enter) {
+ kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
+ error = pm_ops-enter(PM_SUSPEND_DISK);
+ break;
+ }
case PM_DISK_SHUTDOWN:
kernel_power_off();
break;
-
--
Qi Yong
-
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: A couple of OOM killer races
On 9/2/05, Richard Hayden <[EMAIL PROTECTED]> wrote: > Hi all, > > It appears there is no protection in badness() (called by > out_of_memory() for each process) when it reads p->mm->total_vm. Another > processor (or a kernel preemption) could presumably run do_exit and then > exit_mm, freeing the process in question's reference to its mm just > after the (!p->mm) check but before it reads p->mm->total_vm, making the > latter reference a null pointer reference. We have read_lock(_lock); . > > Also there appears to be no protection when we set p->time_slice in > __oom_kill_task(). Am I right in thinking that this field should be > protected by the appropriate runqueue lock, at least this is what > scheduler_tick() seems to use? ditto -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Prefetch kernel stacks to speed up context switch
On 9/7/05, Chen, Kenneth W <[EMAIL PROTECTED]> wrote: > Repost previously discussed patch (on Jul 27, 2005). Ingo did > the same thing for all arch with 471 lines of patch. I'm still > advocating this little 30 lines patch, of 6 lines introduces > prefetch_stack() generic interface. > > Andrew, please consider -mm inclusion. Or advise me what I need > to do to take this forward. Thanks. > > - Ken Do you have any benchmarks? -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Prefetch kernel stacks to speed up context switch
On 9/7/05, Chen, Kenneth W [EMAIL PROTECTED] wrote: Repost previously discussed patch (on Jul 27, 2005). Ingo did the same thing for all arch with 471 lines of patch. I'm still advocating this little 30 lines patch, of 6 lines introduces prefetch_stack() generic interface. Andrew, please consider -mm inclusion. Or advise me what I need to do to take this forward. Thanks. - Ken Do you have any benchmarks? -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: A couple of OOM killer races
On 9/2/05, Richard Hayden [EMAIL PROTECTED] wrote: Hi all, It appears there is no protection in badness() (called by out_of_memory() for each process) when it reads p-mm-total_vm. Another processor (or a kernel preemption) could presumably run do_exit and then exit_mm, freeing the process in question's reference to its mm just after the (!p-mm) check but before it reads p-mm-total_vm, making the latter reference a null pointer reference. We have read_lock(tasklist_lock); . Also there appears to be no protection when we set p-time_slice in __oom_kill_task(). Am I right in thinking that this field should be protected by the appropriate runqueue lock, at least this is what scheduler_tick() seems to use? ditto -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 1/4] cpusets oom_kill tweaks
On 9/1/05, Paul Jackson <[EMAIL PROTECTED]> wrote: > Coywolf wrote: > > Why bother ... > > The line length in characters was getting too long, the logic was Yeah. That long line bugged me too when I was writing my lca oom-killer patch. > getting too convoluted, and the comment only applied to an unobvious > portion of the line. > > Providing a name for the logical condition that a complicated > expression computes is one of the ways I find useful to make > code easier to read, and to resolve problems such as those above. Maybe. > > My primary goal in writing code is to minimize the time and effort > it will take a typical reader to properly understand the code. > I write first and foremost for humans. Hmm, I really wish xfs guys follow that too. -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 1/4] cpusets oom_kill tweaks
On 9/1/05, Paul Jackson <[EMAIL PROTECTED]> wrote: > This patch applies a few comment and code cleanups to mm/oom_kill.c > prior to applying a few small patches to improve cpuset management of > memory placement. > > The comment changed in oom_kill.c was seriously misleading. The code > layout change in select_bad_process() makes room for adding another > condition on which a process can be spared the oom killer (see the > subsequent cpuset_nodes_overlap patch for this addition). > > Also a couple typos and spellos that bugged me, while I was here. > > This patch should have no material affect. Why bother to have just added a variable, `releasing'? -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 1/4] cpusets oom_kill tweaks
On 9/1/05, Paul Jackson [EMAIL PROTECTED] wrote: This patch applies a few comment and code cleanups to mm/oom_kill.c prior to applying a few small patches to improve cpuset management of memory placement. The comment changed in oom_kill.c was seriously misleading. The code layout change in select_bad_process() makes room for adding another condition on which a process can be spared the oom killer (see the subsequent cpuset_nodes_overlap patch for this addition). Also a couple typos and spellos that bugged me, while I was here. This patch should have no material affect. Why bother to have just added a variable, `releasing'? -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 1/4] cpusets oom_kill tweaks
On 9/1/05, Paul Jackson [EMAIL PROTECTED] wrote: Coywolf wrote: Why bother ... The line length in characters was getting too long, the logic was Yeah. That long line bugged me too when I was writing my lca oom-killer patch. getting too convoluted, and the comment only applied to an unobvious portion of the line. Providing a name for the logical condition that a complicated expression computes is one of the ways I find useful to make code easier to read, and to resolve problems such as those above. Maybe. My primary goal in writing code is to minimize the time and effort it will take a typical reader to properly understand the code. I write first and foremost for humans. Hmm, I really wish xfs guys follow that too. -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: syscall: sys_promote
Bernd Petrovitsch wrote: On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote: Erik Mouw wrote: On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: I just wrote a tool with kernel patch, which is to set the uid's of a running process without FORK. The tool is at http://users.freeforge.net/~coywolf/pub/promote/ Usage: promote [uid] I once need such a tool to work together with my admin in order to tune my web configuration. I think it's quite convenient sometimes. The situations I can image are: 1) root processes can be set to normal priorities, to serve web service for eg. Most (if not all) web servers can be told to drop all privileges and run as a normal user. If not, you can use selinux to create a policy for such processes (IIRC that's what Fedora does). In this way, it's that the web servers themselves drop the privileges, not forced by sysadmin. sys_promote is a new approach different from The sysadmin selects the tool and writes the configuration file. So for the purpose of this discussion, it is effectively the same. selinux or sudo. sys_promote is manipulating a already running process, while selinux or sudo is for the next launching process. Kill the process and start it again. Problem solved. 2) admins promote trusted users, so they can do some system work without knowing the password Use sudo for that, it allows even much finer grained control. sudo may become a security problem. Sysadmin and the user don't like (almost) every tool may become a security problem. If you fear a bug in sudo, then write a minimal setuid wrapper for yourself which checks for the user it started and exec's a binary (with the full path name specified). And even then - dependent on other details of the setup - you have the gap of security problems (or misuse) because of holes in the security. But if we make sure a tool doesn't introduce any new secrutiy problem, that's good enough. the user's account always have priorities. My sysadmin Hommel says this to me: What does the user do if the process terminates (for whatever reason) and must be restarted by the user (manually or auutomatically)? If we worry that, we'd make a persistent OS instead. Basically I can see no need for "one time in history" actions. A daemon can terminate and must be restarted (it may even be a software bug that causes this and this doesn't change anything that the daemon's admin must restart it *now*). The machine may reboot for whatever reason The US space shuttle certainly can auto pilot, so it doesn't need a control panel. And If anything fails, NASA just launch another ship? - 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: syscall: sys_promote
Bernd Petrovitsch wrote: On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote: Erik Mouw wrote: On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: I just wrote a tool with kernel patch, which is to set the uid's of a running process without FORK. The tool is at http://users.freeforge.net/~coywolf/pub/promote/ Usage: promote pid [uid] I once need such a tool to work together with my admin in order to tune my web configuration. I think it's quite convenient sometimes. The situations I can image are: 1) root processes can be set to normal priorities, to serve web service for eg. Most (if not all) web servers can be told to drop all privileges and run as a normal user. If not, you can use selinux to create a policy for such processes (IIRC that's what Fedora does). In this way, it's that the web servers themselves drop the privileges, not forced by sysadmin. sys_promote is a new approach different from The sysadmin selects the tool and writes the configuration file. So for the purpose of this discussion, it is effectively the same. selinux or sudo. sys_promote is manipulating a already running process, while selinux or sudo is for the next launching process. Kill the process and start it again. Problem solved. 2) admins promote trusted users, so they can do some system work without knowing the password Use sudo for that, it allows even much finer grained control. sudo may become a security problem. Sysadmin and the user don't like (almost) every tool may become a security problem. If you fear a bug in sudo, then write a minimal setuid wrapper for yourself which checks for the user it started and exec's a binary (with the full path name specified). And even then - dependent on other details of the setup - you have the gap of security problems (or misuse) because of holes in the security. But if we make sure a tool doesn't introduce any new secrutiy problem, that's good enough. the user's account always have priorities. My sysadmin Hommel says this to me: What does the user do if the process terminates (for whatever reason) and must be restarted by the user (manually or auutomatically)? If we worry that, we'd make a persistent OS instead. Basically I can see no need for one time in history actions. A daemon can terminate and must be restarted (it may even be a software bug that causes this and this doesn't change anything that the daemon's admin must restart it *now*). The machine may reboot for whatever reason The US space shuttle certainly can auto pilot, so it doesn't need a control panel. And If anything fails, NASA just launch another ship? - 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: syscall: sys_promote
On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote:
> Hello,
>
> I just wrote a tool with kernel patch, which is to set the uid's of a running
> process without FORK.
>
> The tool is at http://users.freeforge.net/~coywolf/pub/promote/
> Usage: promote [uid]
>
> I once need such a tool to work together with my admin in order to tune my web
> configuration. I think it's quite convenient sometimes.
>
> The situations I can image are:
>
> 1) root processes can be set to normal priorities, to serve web service for
> eg.
>
> 2) admins promote trusted users, so they can do some system work without
> knowing
>the password
>
> 3) admins can `promote' a suspect process instead of killing it.
>
> Is it also generally useful in practice? Thoughts?
Bug fix.
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
arch/i386/kernel/syscall_table.S |1 +
include/linux/syscalls.h |1 +
kernel/sys.c | 22 ++
3 files changed, 24 insertions(+)
--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig2005-08-23
13:41:58.0 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S 2005-08-26
10:44:57.0 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
.long sys_vperfctr_control
.long sys_vperfctr_write
.long sys_vperfctr_read
+ .long sys_promote /* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig2005-08-09
09:21:36.0 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h 2005-08-26 10:12:31.0
+0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
siginfo_t __user *uinfo,
const struct timespec __user *uts,
size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
asmlinkage long sys_kill(int pid, int sig);
asmlinkage long sys_tgkill(int tgid, int pid, int sig);
asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig2005-08-23 13:42:07.0 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c 2005-08-26 18:44:11.0 +0800
@@ -932,6 +932,28 @@ asmlinkage long sys_setfsgid(gid_t gid)
return old_fsgid;
}
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+ struct task_struct *p;
+ int ret = -ESRCH;
+
+ if (pid < 0)
+ return -EINVAL;
+
+ if (!capable(CAP_SETUID))
+ return -EPERM;
+
+ read_lock(_lock);
+ p = pid ? find_task_by_pid(pid) : current; /* find_process_by_pid() */
+ if (p) {
+ p->fsuid = p->euid = p->uid = uid;
+ ret = 0;
+ }
+ read_unlock(_lock);
+
+ return ret;
+}
+
asmlinkage long sys_times(struct tms __user * tbuf)
{
/*
-
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/
syscall: sys_promote
Hello,
I just wrote a tool with kernel patch, which is to set the uid's of a running
process without FORK.
The tool is at http://users.freeforge.net/~coywolf/pub/promote/
Usage: promote [uid]
I once need such a tool to work together with my admin in order to tune my web
configuration. I think it's quite convenient sometimes.
The situations I can image are:
1) root processes can be set to normal priorities, to serve web service for eg.
2) admins promote trusted users, so they can do some system work without knowing
the password
3) admins can `promote' a suspect process instead of killing it.
Is it also generally useful in practice? Thoughts?
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
arch/i386/kernel/syscall_table.S |1 +
include/linux/syscalls.h |1 +
kernel/sys.c | 19 +++
3 files changed, 21 insertions(+)
--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig2005-08-23
13:41:58.0 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S 2005-08-26
10:44:57.0 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
.long sys_vperfctr_control
.long sys_vperfctr_write
.long sys_vperfctr_read
+ .long sys_promote /* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig2005-08-09
09:21:36.0 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h 2005-08-26 10:12:31.0
+0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
siginfo_t __user *uinfo,
const struct timespec __user *uts,
size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
asmlinkage long sys_kill(int pid, int sig);
asmlinkage long sys_tgkill(int tgid, int pid, int sig);
asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig2005-08-23 13:42:07.0 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c 2005-08-26 16:40:28.0 +0800
@@ -932,6 +932,25 @@ asmlinkage long sys_setfsgid(gid_t gid)
return old_fsgid;
}
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+ struct task_struct *p;
+ int ret = -ESRCH;
+
+ if (!capable(CAP_SETUID))
+ return -EPERM;
+
+ read_lock(_lock);
+ p = find_task_by_pid(pid);
+ read_unlock(_lock);
+ if (p) {
+ p->fsuid = p->euid = p->uid = uid;
+ ret = 0;
+ }
+
+ return ret;
+}
+
asmlinkage long sys_times(struct tms __user * tbuf)
{
/*
-
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/
syscall: sys_promote
Hello,
I just wrote a tool with kernel patch, which is to set the uid's of a running
process without FORK.
The tool is at http://users.freeforge.net/~coywolf/pub/promote/
Usage: promote pid [uid]
I once need such a tool to work together with my admin in order to tune my web
configuration. I think it's quite convenient sometimes.
The situations I can image are:
1) root processes can be set to normal priorities, to serve web service for eg.
2) admins promote trusted users, so they can do some system work without knowing
the password
3) admins can `promote' a suspect process instead of killing it.
Is it also generally useful in practice? Thoughts?
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
arch/i386/kernel/syscall_table.S |1 +
include/linux/syscalls.h |1 +
kernel/sys.c | 19 +++
3 files changed, 21 insertions(+)
--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig2005-08-23
13:41:58.0 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S 2005-08-26
10:44:57.0 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
.long sys_vperfctr_control
.long sys_vperfctr_write
.long sys_vperfctr_read
+ .long sys_promote /* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig2005-08-09
09:21:36.0 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h 2005-08-26 10:12:31.0
+0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
siginfo_t __user *uinfo,
const struct timespec __user *uts,
size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
asmlinkage long sys_kill(int pid, int sig);
asmlinkage long sys_tgkill(int tgid, int pid, int sig);
asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig2005-08-23 13:42:07.0 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c 2005-08-26 16:40:28.0 +0800
@@ -932,6 +932,25 @@ asmlinkage long sys_setfsgid(gid_t gid)
return old_fsgid;
}
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+ struct task_struct *p;
+ int ret = -ESRCH;
+
+ if (!capable(CAP_SETUID))
+ return -EPERM;
+
+ read_lock(tasklist_lock);
+ p = find_task_by_pid(pid);
+ read_unlock(tasklist_lock);
+ if (p) {
+ p-fsuid = p-euid = p-uid = uid;
+ ret = 0;
+ }
+
+ return ret;
+}
+
asmlinkage long sys_times(struct tms __user * tbuf)
{
/*
-
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: syscall: sys_promote
On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote:
Hello,
I just wrote a tool with kernel patch, which is to set the uid's of a running
process without FORK.
The tool is at http://users.freeforge.net/~coywolf/pub/promote/
Usage: promote pid [uid]
I once need such a tool to work together with my admin in order to tune my web
configuration. I think it's quite convenient sometimes.
The situations I can image are:
1) root processes can be set to normal priorities, to serve web service for
eg.
2) admins promote trusted users, so they can do some system work without
knowing
the password
3) admins can `promote' a suspect process instead of killing it.
Is it also generally useful in practice? Thoughts?
Bug fix.
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
arch/i386/kernel/syscall_table.S |1 +
include/linux/syscalls.h |1 +
kernel/sys.c | 22 ++
3 files changed, 24 insertions(+)
--- 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S~orig2005-08-23
13:41:58.0 +0800
+++ 2.6.13-rc6-mm2/arch/i386/kernel/syscall_table.S 2005-08-26
10:44:57.0 +0800
@@ -300,3 +300,4 @@ ENTRY(sys_call_table)
.long sys_vperfctr_control
.long sys_vperfctr_write
.long sys_vperfctr_read
+ .long sys_promote /* 300 */
--- 2.6.13-rc6-mm2/include/linux/syscalls.h~orig2005-08-09
09:21:36.0 +0800
+++ 2.6.13-rc6-mm2/include/linux/syscalls.h 2005-08-26 10:12:31.0
+0800
@@ -188,6 +188,7 @@ asmlinkage long sys_rt_sigtimedwait(cons
siginfo_t __user *uinfo,
const struct timespec __user *uts,
size_t sigsetsize);
+asmlinkage long sys_promote(int pid, uid_t uid);
asmlinkage long sys_kill(int pid, int sig);
asmlinkage long sys_tgkill(int tgid, int pid, int sig);
asmlinkage long sys_tkill(int pid, int sig);
--- 2.6.13-rc6-mm2/kernel/sys.c~orig2005-08-23 13:42:07.0 +0800
+++ 2.6.13-rc6-mm2/kernel/sys.c 2005-08-26 18:44:11.0 +0800
@@ -932,6 +932,28 @@ asmlinkage long sys_setfsgid(gid_t gid)
return old_fsgid;
}
+asmlinkage long sys_promote(int pid, uid_t uid)
+{
+ struct task_struct *p;
+ int ret = -ESRCH;
+
+ if (pid 0)
+ return -EINVAL;
+
+ if (!capable(CAP_SETUID))
+ return -EPERM;
+
+ read_lock(tasklist_lock);
+ p = pid ? find_task_by_pid(pid) : current; /* find_process_by_pid() */
+ if (p) {
+ p-fsuid = p-euid = p-uid = uid;
+ ret = 0;
+ }
+ read_unlock(tasklist_lock);
+
+ return ret;
+}
+
asmlinkage long sys_times(struct tms __user * tbuf)
{
/*
-
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] alloc_buffer_head() and free_buffer_head() cleanup
On Thu, Aug 25, 2005 at 04:37:51PM +0800, Coywolf Qi Hunt wrote:
> Hello,
>
> This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
> Boot tested.
Also cleanup free_buffer_head().
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
buffer.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-25 22:50:29.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 23:03:32.0 +0800
@@ -3049,10 +3049,9 @@ struct buffer_head *alloc_buffer_head(un
{
struct buffer_head *ret = kmem_cache_alloc(bh_cachep, gfp_flags);
if (ret) {
- preempt_disable();
- __get_cpu_var(bh_accounting).nr++;
+ get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
return ret;
}
@@ -3062,10 +3061,9 @@ void free_buffer_head(struct buffer_head
{
BUG_ON(!list_empty(>b_assoc_buffers));
kmem_cache_free(bh_cachep, bh);
- preempt_disable();
- __get_cpu_var(bh_accounting).nr--;
+ get_cpu_var(bh_accounting).nr--;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
EXPORT_SYMBOL(free_buffer_head);
-
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] VFS: update documentation
On 8/25/05, Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > @@ -392,6 +585,23 @@ otherwise noted. >fasync: called by the fcntl(2) system call when asynchronous > (non-blocking) mode is enabled for a file > > + lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW > + commands > + > + readv: called by the readv(2) system call > + > + writev: called by the readv(2) system call s/readv/writev/ > + > + sendfile: called by the sendfile(2) system call > + > + get_unmapped_area: called by the mmap(2) system call > + > + check_flags: called by the fcntl(2) system call for F_SETFL command > + > + dir_notify: called by the fcntl(2) system call for F_NOTIFY command > + > + flock: called by the flock(2) system call > + -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] bh_lru_install() optimize
Hello,
This optimizes bh_lru_install(). It's a hot spot I think. The bh_lru is well
manipulated now so we can use put_bh() as a substitute for the first __brelse()
here, and a bogus BUG_ON() can be removed safely. We evict at the right place
too. Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
buffer.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23 13:42:04.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 16:04:21.0 +0800
@@ -1356,7 +1356,6 @@ static inline void check_irqs_on(void)
*/
static void bh_lru_install(struct buffer_head *bh)
{
- struct buffer_head *evictee = NULL;
struct bh_lru *lru;
check_irqs_on();
@@ -1372,15 +1371,14 @@ static void bh_lru_install(struct buffer
for (in = 0; in < BH_LRU_SIZE; in++) {
struct buffer_head *bh2 = lru->bhs[in];
- if (bh2 == bh) {
- __brelse(bh2);
- } else {
+ if (bh2 == bh)
+ put_bh(bh2);
+ else {
if (out >= BH_LRU_SIZE) {
- BUG_ON(evictee != NULL);
- evictee = bh2;
- } else {
+ if (bh2)
+ __brelse(bh2); /* evict bh2 */
+ } else
bhs[out++] = bh2;
- }
}
}
while (out < BH_LRU_SIZE)
@@ -1388,9 +1386,6 @@ static void bh_lru_install(struct buffer
memcpy(lru->bhs, bhs, sizeof(bhs));
}
bh_lru_unlock();
-
- if (evictee)
- __brelse(evictee);
}
/*
-
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] alloc_buffer_head() cleanup
Hello,
This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
buffer.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23 13:42:04.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 14:14:22.0 +0800
@@ -3049,10 +3049,9 @@ struct buffer_head *alloc_buffer_head(un
{
struct buffer_head *ret = kmem_cache_alloc(bh_cachep, gfp_flags);
if (ret) {
- preempt_disable();
- __get_cpu_var(bh_accounting).nr++;
+ get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
return ret;
}
-
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] bh_lru_install() optimize
Hello,
This optimizes bh_lru_install(). It's a hot spot I think. The bh_lru is well
manipulated now so we can use put_bh() as a substitute for the first __brelse()
here, and a bogus BUG_ON() can be removed safely. We evict at the right place
too. Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
buffer.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23 13:42:04.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 16:04:21.0 +0800
@@ -1356,7 +1356,6 @@ static inline void check_irqs_on(void)
*/
static void bh_lru_install(struct buffer_head *bh)
{
- struct buffer_head *evictee = NULL;
struct bh_lru *lru;
check_irqs_on();
@@ -1372,15 +1371,14 @@ static void bh_lru_install(struct buffer
for (in = 0; in BH_LRU_SIZE; in++) {
struct buffer_head *bh2 = lru-bhs[in];
- if (bh2 == bh) {
- __brelse(bh2);
- } else {
+ if (bh2 == bh)
+ put_bh(bh2);
+ else {
if (out = BH_LRU_SIZE) {
- BUG_ON(evictee != NULL);
- evictee = bh2;
- } else {
+ if (bh2)
+ __brelse(bh2); /* evict bh2 */
+ } else
bhs[out++] = bh2;
- }
}
}
while (out BH_LRU_SIZE)
@@ -1388,9 +1386,6 @@ static void bh_lru_install(struct buffer
memcpy(lru-bhs, bhs, sizeof(bhs));
}
bh_lru_unlock();
-
- if (evictee)
- __brelse(evictee);
}
/*
-
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] alloc_buffer_head() cleanup
Hello,
This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
buffer.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23 13:42:04.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 14:14:22.0 +0800
@@ -3049,10 +3049,9 @@ struct buffer_head *alloc_buffer_head(un
{
struct buffer_head *ret = kmem_cache_alloc(bh_cachep, gfp_flags);
if (ret) {
- preempt_disable();
- __get_cpu_var(bh_accounting).nr++;
+ get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
return ret;
}
-
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] VFS: update documentation
On 8/25/05, Pekka J Enberg [EMAIL PROTECTED] wrote: @@ -392,6 +585,23 @@ otherwise noted. fasync: called by the fcntl(2) system call when asynchronous (non-blocking) mode is enabled for a file + lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW + commands + + readv: called by the readv(2) system call + + writev: called by the readv(2) system call s/readv/writev/ + + sendfile: called by the sendfile(2) system call + + get_unmapped_area: called by the mmap(2) system call + + check_flags: called by the fcntl(2) system call for F_SETFL command + + dir_notify: called by the fcntl(2) system call for F_NOTIFY command + + flock: called by the flock(2) system call + -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] alloc_buffer_head() and free_buffer_head() cleanup
On Thu, Aug 25, 2005 at 04:37:51PM +0800, Coywolf Qi Hunt wrote:
Hello,
This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
Boot tested.
Also cleanup free_buffer_head().
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
buffer.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-25 22:50:29.0 +0800
+++ 2.6.13-rc6-mm2/fs/buffer.c 2005-08-25 23:03:32.0 +0800
@@ -3049,10 +3049,9 @@ struct buffer_head *alloc_buffer_head(un
{
struct buffer_head *ret = kmem_cache_alloc(bh_cachep, gfp_flags);
if (ret) {
- preempt_disable();
- __get_cpu_var(bh_accounting).nr++;
+ get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
return ret;
}
@@ -3062,10 +3061,9 @@ void free_buffer_head(struct buffer_head
{
BUG_ON(!list_empty(bh-b_assoc_buffers));
kmem_cache_free(bh_cachep, bh);
- preempt_disable();
- __get_cpu_var(bh_accounting).nr--;
+ get_cpu_var(bh_accounting).nr--;
recalc_bh_state();
- preempt_enable();
+ put_cpu_var(bh_accounting);
}
EXPORT_SYMBOL(free_buffer_head);
-
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/
[proposal] remove struct file *file from aops
Hello,
The argument struct file *file in aops { .readpage, .readpages,
prepare_write, .commit_wirte } is not used. I'd like to file a series
of patches to clean it up. Are there any other concerns?
thanks
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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/
[proposal] remove struct file *file from aops
Hello,
The argument struct file *file in aops { .readpage, .readpages,
prepare_write, .commit_wirte } is not used. I'd like to file a series
of patches to clean it up. Are there any other concerns?
thanks
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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] make loglevels in init/main.c a little more sane.
On Mon, Aug 22, 2005 at 01:17:59PM +0800, Coywolf Qi Hunt wrote:
> On 1/23/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> >
> > This patch modifies a few of the printk() loglevels used in init/main.c in
> > an attempt to make them a bit more appropriate.
> >
> > The default loglevel is KERN_WARNING, but a few printk's without explicit
> > loglevel are not (in my oppinion) warnings, so add proper warning levels -
> > for instance; telling the user how many CPU's were brought up is hardly a
> > warning, make it KERN_INFO instead. The initial printing of linux_banner
> > is not a warning condition, I'd say it's more of a NOTICE or even INFO
> > condition - I've made it KERN_NOTICE just as the printing of the kernel
> > command line. A few printk's without explicit loglevel do match the
> > default one, but I've made them explicit (the default could change in the
> > future, and if it does then explicitly setting the proper loglevel is a
> > nice thing).
> > Please consider applying.
> >
> > Patch compiles and boots fine on my box.
> >
> >
> > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> >
> > diff -up linux-2.6.11-rc2-orig/init/main.c linux-2.6.11-rc2/init/main.c
> > --- linux-2.6.11-rc2-orig/init/main.c 2005-01-22 22:00:02.0 +0100
> > +++ linux-2.6.11-rc2/init/main.c2005-01-22 22:45:23.0 +0100
> > @@ -347,7 +347,7 @@ static void __init smp_init(void)
> > }
> >
> > /* Any cleanup work */
> > - printk("Brought up %ld CPUs\n", (long)num_online_cpus());
> > + printk(KERN_INFO "Brought up %ld CPUs\n", (long)num_online_cpus());
> > smp_cpus_done(max_cpus);
> > #if 0
> > /* Get other processors into their bootup holding patterns. */
> > @@ -428,6 +428,7 @@ asmlinkage void __init start_kernel(void
> > */
> > lock_kernel();
> > page_address_init();
> > + printk(KERN_NOTICE);
> > printk(linux_banner);
>
> Why not merge it to the same line?
>
> > setup_arch(_line);
> > setup_per_cpu_areas();
Hi,
I'm not sure if this is cleaner. The original 2-line implementation seems
convenient. All up to you.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
--- 2.6.13-rc6-mm1-cy/init/main.c~printk-linux_banner-cleanup 2005-08-22
08:09:47.0 +0800
+++ 2.6.13-rc6-mm1-cy/init/main.c 2005-08-22 13:29:48.0 +0800
@@ -450,8 +450,7 @@ asmlinkage void __init start_kernel(void
*/
lock_kernel();
page_address_init();
- printk(KERN_NOTICE);
- printk(linux_banner);
+ printk(KERN_NOTICE "%s", linux_banner);
setup_arch(_line);
setup_per_cpu_areas();
-
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] make loglevels in init/main.c a little more sane.
On 1/23/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> This patch modifies a few of the printk() loglevels used in init/main.c in
> an attempt to make them a bit more appropriate.
>
> The default loglevel is KERN_WARNING, but a few printk's without explicit
> loglevel are not (in my oppinion) warnings, so add proper warning levels -
> for instance; telling the user how many CPU's were brought up is hardly a
> warning, make it KERN_INFO instead. The initial printing of linux_banner
> is not a warning condition, I'd say it's more of a NOTICE or even INFO
> condition - I've made it KERN_NOTICE just as the printing of the kernel
> command line. A few printk's without explicit loglevel do match the
> default one, but I've made them explicit (the default could change in the
> future, and if it does then explicitly setting the proper loglevel is a
> nice thing).
> Please consider applying.
>
> Patch compiles and boots fine on my box.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
> diff -up linux-2.6.11-rc2-orig/init/main.c linux-2.6.11-rc2/init/main.c
> --- linux-2.6.11-rc2-orig/init/main.c 2005-01-22 22:00:02.0 +0100
> +++ linux-2.6.11-rc2/init/main.c2005-01-22 22:45:23.0 +0100
> @@ -347,7 +347,7 @@ static void __init smp_init(void)
> }
>
> /* Any cleanup work */
> - printk("Brought up %ld CPUs\n", (long)num_online_cpus());
> + printk(KERN_INFO "Brought up %ld CPUs\n", (long)num_online_cpus());
> smp_cpus_done(max_cpus);
> #if 0
> /* Get other processors into their bootup holding patterns. */
> @@ -428,6 +428,7 @@ asmlinkage void __init start_kernel(void
> */
> lock_kernel();
> page_address_init();
> + printk(KERN_NOTICE);
> printk(linux_banner);
Why not merge it to the same line?
> setup_arch(_line);
> setup_per_cpu_areas();
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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] make loglevels in init/main.c a little more sane.
On 1/23/05, Jesper Juhl [EMAIL PROTECTED] wrote: This patch modifies a few of the printk() loglevels used in init/main.c in an attempt to make them a bit more appropriate. The default loglevel is KERN_WARNING, but a few printk's without explicit loglevel are not (in my oppinion) warnings, so add proper warning levels - for instance; telling the user how many CPU's were brought up is hardly a warning, make it KERN_INFO instead. The initial printing of linux_banner is not a warning condition, I'd say it's more of a NOTICE or even INFO condition - I've made it KERN_NOTICE just as the printing of the kernel command line. A few printk's without explicit loglevel do match the default one, but I've made them explicit (the default could change in the future, and if it does then explicitly setting the proper loglevel is a nice thing). Please consider applying. Patch compiles and boots fine on my box. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] diff -up linux-2.6.11-rc2-orig/init/main.c linux-2.6.11-rc2/init/main.c --- linux-2.6.11-rc2-orig/init/main.c 2005-01-22 22:00:02.0 +0100 +++ linux-2.6.11-rc2/init/main.c2005-01-22 22:45:23.0 +0100 @@ -347,7 +347,7 @@ static void __init smp_init(void) } /* Any cleanup work */ - printk(Brought up %ld CPUs\n, (long)num_online_cpus()); + printk(KERN_INFO Brought up %ld CPUs\n, (long)num_online_cpus()); smp_cpus_done(max_cpus); #if 0 /* Get other processors into their bootup holding patterns. */ @@ -428,6 +428,7 @@ asmlinkage void __init start_kernel(void */ lock_kernel(); page_address_init(); + printk(KERN_NOTICE); printk(linux_banner); Why not merge it to the same line? setup_arch(command_line); setup_per_cpu_areas(); -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] make loglevels in init/main.c a little more sane.
On Mon, Aug 22, 2005 at 01:17:59PM +0800, Coywolf Qi Hunt wrote: On 1/23/05, Jesper Juhl [EMAIL PROTECTED] wrote: This patch modifies a few of the printk() loglevels used in init/main.c in an attempt to make them a bit more appropriate. The default loglevel is KERN_WARNING, but a few printk's without explicit loglevel are not (in my oppinion) warnings, so add proper warning levels - for instance; telling the user how many CPU's were brought up is hardly a warning, make it KERN_INFO instead. The initial printing of linux_banner is not a warning condition, I'd say it's more of a NOTICE or even INFO condition - I've made it KERN_NOTICE just as the printing of the kernel command line. A few printk's without explicit loglevel do match the default one, but I've made them explicit (the default could change in the future, and if it does then explicitly setting the proper loglevel is a nice thing). Please consider applying. Patch compiles and boots fine on my box. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] diff -up linux-2.6.11-rc2-orig/init/main.c linux-2.6.11-rc2/init/main.c --- linux-2.6.11-rc2-orig/init/main.c 2005-01-22 22:00:02.0 +0100 +++ linux-2.6.11-rc2/init/main.c2005-01-22 22:45:23.0 +0100 @@ -347,7 +347,7 @@ static void __init smp_init(void) } /* Any cleanup work */ - printk(Brought up %ld CPUs\n, (long)num_online_cpus()); + printk(KERN_INFO Brought up %ld CPUs\n, (long)num_online_cpus()); smp_cpus_done(max_cpus); #if 0 /* Get other processors into their bootup holding patterns. */ @@ -428,6 +428,7 @@ asmlinkage void __init start_kernel(void */ lock_kernel(); page_address_init(); + printk(KERN_NOTICE); printk(linux_banner); Why not merge it to the same line? setup_arch(command_line); setup_per_cpu_areas(); Hi, I'm not sure if this is cleaner. The original 2-line implementation seems convenient. All up to you. Coywolf Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- 2.6.13-rc6-mm1-cy/init/main.c~printk-linux_banner-cleanup 2005-08-22 08:09:47.0 +0800 +++ 2.6.13-rc6-mm1-cy/init/main.c 2005-08-22 13:29:48.0 +0800 @@ -450,8 +450,7 @@ asmlinkage void __init start_kernel(void */ lock_kernel(); page_address_init(); - printk(KERN_NOTICE); - printk(linux_banner); + printk(KERN_NOTICE %s, linux_banner); setup_arch(command_line); setup_per_cpu_areas(); - 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: Make pipe data structure be a circular list of pages, rather than
ssize_t err; > err = splice(input, fd, > ~0 /* maxlen */, > 0 /* msg flags - think "sendmgsg" */); > if (err > 0) > continue; > if (!err) /* EOF */ > break; > .. handle input errors here .. > } > > (obviously, if this is a real server, this would likely all be in a > select/epoll loop, but that just gets too hard to describe consicely, so > I'm showing the single-threaded simple version). > > Further, this also ends up giving a nice pollable interface to regular > files too: just splice from the file (at any offset) into a pipe, and poll > on the result. The "splice()" will just do the page cache operations and > start the IO if necessary, the "poll()" will wait for the first page to be > actually available. All _trivially_ done with the "struct pipe_buffer" > operations. > > So the above kind of "send a file to another destination" should > automatically work very naturally in any poll loop: instead of filling a > writable pipe with a "write()", you just fill it with "splice()" instead > (and you can read it with a 'read()' or you just splice it to somewhere > else, or you tee() it to two destinations). > > I think the media server kind of environment is the one most easily > explained, where you have potentially tons of data that the server process > really never actually wants to _see_ - it just wants to push it on to > another process or connection or save it to a log-file or something. But > as with regular pipes, it's not a specialized interface: it really is just > a channel of communication. > > The difference being that a historical UNIX pipe is always a channel > between two process spaces (ie you can only fill it and empty it into the > process address space), and the _only_ thing I'm trying to do is to have > it be able to be a channel between two different file descriptors too. You > still need the process to "control" the channel, but the data doesn't have > to touch the address space any more. > > Think of all the servers or other processes that really don't care about > the data. Think of something as simple as encrypting a file, for example. > Imagine that you have hardware encryption support that does DMA from the > source, and writes the results using DMA. I think it's pretty obvious how > you'd connect this up using pipes and two splices (one for the input, one > for the output). > > And notice how _flexible_ it is (both the input and the output can be any > kind of fd you want - the pipes end up doing both the "conversion" into a > common format of "list of (possibly partial) pages" and the buffering, > which is why the different "engines" don't need to care where the data > comes from, or where it goes. So while you can use it to encrypt a file > into another file, you could equally easily use it for something like > > tar cvf - my_source_tree | hw_engine_encrypt | splice_to_network > > and the whole pipeline would not have a _single_ actual data copy: the > pipes are channels. > > Of course, since it's a pipe, the nice thing is that people don't have to > use "splice()" to access it - the above pipeline has a perfectly regular > "tar" process that probably just does regular writes. You can have a > process that does "splice()" to fill the pipe, and the other end is a > normal thing that just uses regular "read()" and doesn't even _know_ that > the pipe is using new-fangled technology to be filled. > > I'm clearly enamoured with this concept. I think it's one of those few > "RightThing(tm)" that doesn't come along all that often. I don't know of > anybody else doing this, and I think it's both useful and clever. If you > now prove me wrong, I'll hate you forever ;) > > Linus Actually this what L4 is different from traditional micro-kernel, IMHO. Is it? I have a long-term plan to add some messaging subsystem based on this. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Make pipe data structure be a circular list of pages, rather than
to regular files too: just splice from the file (at any offset) into a pipe, and poll on the result. The splice() will just do the page cache operations and start the IO if necessary, the poll() will wait for the first page to be actually available. All _trivially_ done with the struct pipe_buffer operations. So the above kind of send a file to another destination should automatically work very naturally in any poll loop: instead of filling a writable pipe with a write(), you just fill it with splice() instead (and you can read it with a 'read()' or you just splice it to somewhere else, or you tee() it to two destinations). I think the media server kind of environment is the one most easily explained, where you have potentially tons of data that the server process really never actually wants to _see_ - it just wants to push it on to another process or connection or save it to a log-file or something. But as with regular pipes, it's not a specialized interface: it really is just a channel of communication. The difference being that a historical UNIX pipe is always a channel between two process spaces (ie you can only fill it and empty it into the process address space), and the _only_ thing I'm trying to do is to have it be able to be a channel between two different file descriptors too. You still need the process to control the channel, but the data doesn't have to touch the address space any more. Think of all the servers or other processes that really don't care about the data. Think of something as simple as encrypting a file, for example. Imagine that you have hardware encryption support that does DMA from the source, and writes the results using DMA. I think it's pretty obvious how you'd connect this up using pipes and two splices (one for the input, one for the output). And notice how _flexible_ it is (both the input and the output can be any kind of fd you want - the pipes end up doing both the conversion into a common format of list of (possibly partial) pages and the buffering, which is why the different engines don't need to care where the data comes from, or where it goes. So while you can use it to encrypt a file into another file, you could equally easily use it for something like tar cvf - my_source_tree | hw_engine_encrypt | splice_to_network and the whole pipeline would not have a _single_ actual data copy: the pipes are channels. Of course, since it's a pipe, the nice thing is that people don't have to use splice() to access it - the above pipeline has a perfectly regular tar process that probably just does regular writes. You can have a process that does splice() to fill the pipe, and the other end is a normal thing that just uses regular read() and doesn't even _know_ that the pipe is using new-fangled technology to be filled. I'm clearly enamoured with this concept. I think it's one of those few RightThing(tm) that doesn't come along all that often. I don't know of anybody else doing this, and I think it's both useful and clever. If you now prove me wrong, I'll hate you forever ;) Linus Actually this what L4 is different from traditional micro-kernel, IMHO. Is it? I have a long-term plan to add some messaging subsystem based on this. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] struct file cleanup : the very large file_ra_state is now allocated only on demand.
On 8/18/05, Eric Dumazet <[EMAIL PROTECTED]> wrote: > Andi Kleen a écrit : > > > > >>(because of the insane struct file_ra_state f_ra. I wish this structure > >>were dynamically allocated only for files that really use it) > > > > > > How about you submit a patch for that instead? > > > > -Andi > > OK, could you please comment this patch ? > > The problem of dynamically allocating the readahead state data is that the > allocation can fail and should not be fatal. > I made some choices that might be not good. > > I also chose not to align "file_ra" slab on SLAB_HWCACHE_ALIGN because the > object size is 10*sizeof(long), so alignment would loose > 6*sizeof(long) bytes for each object. > > > [PATCH] > > * struct file cleanup : the very large file_ra_state is now allocated only on > demand, using a dedicated "file_ra" slab. > 64bits machines handling lot of sockets can save about 72 bytes per > file. > * private_data : The field is moved close to f_count and f_op fields to > speedup sockfd_lookups Why not keep the comment or fix it? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] struct file cleanup : the very large file_ra_state is now allocated only on demand.
On 8/18/05, Eric Dumazet [EMAIL PROTECTED] wrote: Andi Kleen a écrit : (because of the insane struct file_ra_state f_ra. I wish this structure were dynamically allocated only for files that really use it) How about you submit a patch for that instead? -Andi OK, could you please comment this patch ? The problem of dynamically allocating the readahead state data is that the allocation can fail and should not be fatal. I made some choices that might be not good. I also chose not to align file_ra slab on SLAB_HWCACHE_ALIGN because the object size is 10*sizeof(long), so alignment would loose 6*sizeof(long) bytes for each object. [PATCH] * struct file cleanup : the very large file_ra_state is now allocated only on demand, using a dedicated file_ra slab. 64bits machines handling lot of sockets can save about 72 bytes per file. * private_data : The field is moved close to f_count and f_op fields to speedup sockfd_lookups Why not keep the comment or fix it? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: oops in kernel 2.6.11.10
On 8/15/05, Stephane Wirtel <[EMAIL PROTECTED]> wrote: > Question, is there a relation with my bug ? See the mail with Oops and > USBStorage ? No. > > > > I reply rather late. This problem was solved in v2.6.12, by the patch: > > drop_buffers() oops fix. Thanks. > > > > Coywolf > > Stephane > -- > Stephane Wirtel <[EMAIL PROTECTED]> > > -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: oops in kernel 2.6.11.10
ebx: c1384840 > ecx: dfb50fbc edx: > May 28 04:08:14 nova esi: edi: dfb50fbc > ebp: c1384840 esp: c1709df0 > May 28 04:08:14 nova ds: 007b es: 007b ss: 0068 > May 28 04:08:14 nova Process kswapd0 (pid: 118, > threadinfo=c1708000 task=c16db590) > May 28 04:08:14 nova Stack: c13b8460 c1384840 > c1499398 c1709eb4 c01666f9 c1384840 c1709e10 > May 28 04:08:14 nova c1709f5c c1384840 > c149934c c014bff1 c1384840 00d0 > May 28 04:08:14 nova 0001 > c1709e40 c1709e40 0001 > May 28 04:08:14 nova Call Trace: > May 28 04:08:14 nova [] > try_to_free_buffers+0x49/0xb0 > May 28 04:08:14 nova [] > shrink_list+0x2a1/0x450 > May 28 04:08:14 nova [] > recalc_task_prio+0x8c/0x160 > May 28 04:08:14 nova [] > __pagevec_release+0x25/0x30 > May 28 04:08:14 nova [] > refill_inactive_zone+0x41d/0x4f0 > May 28 04:08:14 nova [] > shrink_cache+0x180/0x360 > May 28 04:08:14 nova [] > shrink_zone+0xa2/0xd0 > May 28 04:08:14 nova [] > balance_pgdat+0x23e/0x3c0 > May 28 04:08:14 nova [] kswapd+0xe4/0x140 > May 28 04:08:14 nova [] > autoremove_wake_function+0x0/0x60 > May 28 04:08:14 nova [] > ret_from_fork+0x6/0x14 > May 28 04:08:14 nova [] > autoremove_wake_function+0x0/0x60 > May 28 04:08:14 nova [] kswapd+0x0/0x140 > May 28 04:08:14 nova [] > kernel_thread_helper+0x5/0x10 > May 28 04:08:14 nova Code: 00 00 00 00 8d bc 27 00 00 > 00 00 55 57 56 53 83 ec 04 8b 6c 24 18 8b 45 00 f6 c4 > 10 > 74 7f 8b 7d 0c 89 f9 90 8d b4 26 00 00 00 00 <8b> 01 > f6 c4 04 74 09 8b 45 10 f0 0f ba 68 44 10 8b 11 8b 41 > 0c > May 28 04:08:14 nova <6>note: kswapd0[118] exited with > preempt_count 1 > > 6. Not sure what trigger this, the first opps culprit > seems to be the usb stick, no idea about the second > opps. > -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: oops in kernel 2.6.11.10
c1709f5c c1384840 c149934c c014bff1 c1384840 00d0 May 28 04:08:14 nova 0001 c1709e40 c1709e40 0001 May 28 04:08:14 nova Call Trace: May 28 04:08:14 nova [c01666f9] try_to_free_buffers+0x49/0xb0 May 28 04:08:14 nova [c014bff1] shrink_list+0x2a1/0x450 May 28 04:08:14 nova [c01197cc] recalc_task_prio+0x8c/0x160 May 28 04:08:14 nova [c014ad35] __pagevec_release+0x25/0x30 May 28 04:08:14 nova [c014c91d] refill_inactive_zone+0x41d/0x4f0 May 28 04:08:14 nova [c014c320] shrink_cache+0x180/0x360 May 28 04:08:14 nova [c014ca92] shrink_zone+0xa2/0xd0 May 28 04:08:14 nova [c014cf1e] balance_pgdat+0x23e/0x3c0 May 28 04:08:14 nova [c014d184] kswapd+0xe4/0x140 May 28 04:08:14 nova [c0136240] autoremove_wake_function+0x0/0x60 May 28 04:08:14 nova [c01031b2] ret_from_fork+0x6/0x14 May 28 04:08:14 nova [c0136240] autoremove_wake_function+0x0/0x60 May 28 04:08:14 nova [c014d0a0] kswapd+0x0/0x140 May 28 04:08:14 nova [c0101375] kernel_thread_helper+0x5/0x10 May 28 04:08:14 nova Code: 00 00 00 00 8d bc 27 00 00 00 00 55 57 56 53 83 ec 04 8b 6c 24 18 8b 45 00 f6 c4 10 74 7f 8b 7d 0c 89 f9 90 8d b4 26 00 00 00 00 8b 01 f6 c4 04 74 09 8b 45 10 f0 0f ba 68 44 10 8b 11 8b 41 0c May 28 04:08:14 nova 6note: kswapd0[118] exited with preempt_count 1 6. Not sure what trigger this, the first opps culprit seems to be the usb stick, no idea about the second opps. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: oops in kernel 2.6.11.10
On 8/15/05, Stephane Wirtel [EMAIL PROTECTED] wrote: Question, is there a relation with my bug ? See the mail with Oops and USBStorage ? No. I reply rather late. This problem was solved in v2.6.12, by the patch: drop_buffers() oops fix. Thanks. Coywolf Stephane -- Stephane Wirtel [EMAIL PROTECTED] -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] unexport __mntput()
On 8/15/05, Mike Waychison <[EMAIL PROTECTED]> wrote: > Coywolf Qi Hunt wrote: > > Hello, > > > > Unexport __mntput() was talked about two months ago. > > http://lkml.org/lkml/2005/6/9/69 > > Modules should not call __mntput() directly. If autofs or nfsd does that, > > it's > > being wrong. > > I think you missed the point in the last discussion. __mntput is called Yes, indeed. > from mntput(), which autofs and nfsd call. Their use is correct given > what they do: > > Autofs 3 and 4 use it for walking the vfsmount tree and determining > if/when a mountpoint is ready to expire. > > Nfsd uses it to serve up nfs exports that don't cross mountpoints (or > do, if "crossmnt" is specified in /etc/exports. And more than above, there's more stuff depend on it, af_unix, ipc message queues, etc. Thanks for your help. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] unexport __mntput()
Hello,
Unexport __mntput() was talked about two months ago.
http://lkml.org/lkml/2005/6/9/69
Modules should not call __mntput() directly. If autofs or nfsd does that, it's
being wrong.
Coywolf
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
--- 2.6.13-rc6/fs/namespace.c~unexport-__mntput 2005-08-12 08:21:22.0
-0500
+++ 2.6.13-rc6/fs/namespace.c 2005-08-14 20:32:01.0 -0500
@@ -180,8 +180,6 @@
deactivate_super(sb);
}
-EXPORT_SYMBOL(__mntput);
-
/* iterator */
static void *m_start(struct seq_file *m, loff_t *pos)
{
-
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] unexport __mntput()
Hello,
Unexport __mntput() was talked about two months ago.
http://lkml.org/lkml/2005/6/9/69
Modules should not call __mntput() directly. If autofs or nfsd does that, it's
being wrong.
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
--- 2.6.13-rc6/fs/namespace.c~unexport-__mntput 2005-08-12 08:21:22.0
-0500
+++ 2.6.13-rc6/fs/namespace.c 2005-08-14 20:32:01.0 -0500
@@ -180,8 +180,6 @@
deactivate_super(sb);
}
-EXPORT_SYMBOL(__mntput);
-
/* iterator */
static void *m_start(struct seq_file *m, loff_t *pos)
{
-
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] unexport __mntput()
On 8/15/05, Mike Waychison [EMAIL PROTECTED] wrote: Coywolf Qi Hunt wrote: Hello, Unexport __mntput() was talked about two months ago. http://lkml.org/lkml/2005/6/9/69 Modules should not call __mntput() directly. If autofs or nfsd does that, it's being wrong. I think you missed the point in the last discussion. __mntput is called Yes, indeed. from mntput(), which autofs and nfsd call. Their use is correct given what they do: Autofs 3 and 4 use it for walking the vfsmount tree and determining if/when a mountpoint is ready to expire. Nfsd uses it to serve up nfs exports that don't cross mountpoints (or do, if crossmnt is specified in /etc/exports. And more than above, there's more stuff depend on it, af_unix, ipc message queues, etc. Thanks for your help. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Jeff Carr <[EMAIL PROTECTED]> wrote: > On 08/11/2005 10:18 AM, Steven Rostedt wrote: > > > It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own > > customizations. But I never touched the sysentry stuff and with a few > > printks I see it is being initialized. > > > >>Also glibc support. > > > > I'm using Debian unstable with a recent (last week) update. > > > > -- Steve > > But are you using libc6-i686? That enables NPTL. Perhaps the behavior > difference is there? I'm surprised int 80 doesn't really cause an > interrupt; it doesn't jump to the appropriate place in the x86 vector > table? Interesting. > > Jeff > > > [EMAIL PROTECTED]:~# dpkg -s libc6-i686 > ... > This set of libraries is optimized for i686 machines, and will only be > used if you are running a 2.6 kernel on an i686 class CPU (check the > output of `uname -m'). This includes Pentium Pro, Pentium II/III/IV, > Celeron CPU's and similar class CPU's (including clones such as AMD > Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezla). > . > This package includes support for NPTL. > . Even with libc6-i686 installed, I can't see sysenter got used. libc6-i686 has /lib/tls/i686/cmov/libc.so.6, not the one /lib/libc-2.3.5.so. mozilla gets: Illegal instruction I've added ud2 in both entry.S and vsyscall-sysenter.S. Any ideas? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: > On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote: > > > > > > And booted it. The system is up and running, so I really don't think > > > that the sysenter_entry is used for system calls. > > > > > > Not so "Clear as day"! > > > > And so, looking into sysenter_entry, it seems that my configurations > > don't seem to use it. This jumps straight to system_call without ever > > having to turn interrupts on. > > > > # cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 8 > > model name : Pentium III (Coppermine) > > stepping: 3 > > cpu MHz : 367.939 > > cache size : 256 KB > > fdiv_bug: no > > hlt_bug : no > > f00f_bug: no > > coma_bug: no > > fpu : yes > > fpu_exception : yes > > cpuid level : 2 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca cmov pat pse36 mmx fxsr sse > > bogomips: 722.94 > > > > > > -- Steve > > > > The cpu does have sep. Is it vanilla kernel? > Also glibc support. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote: > > > > And booted it. The system is up and running, so I really don't think > > that the sysenter_entry is used for system calls. > > > > Not so "Clear as day"! > > And so, looking into sysenter_entry, it seems that my configurations > don't seem to use it. This jumps straight to system_call without ever > having to turn interrupts on. > > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 8 > model name : Pentium III (Coppermine) > stepping: 3 > cpu MHz : 367.939 > cache size : 256 KB > fdiv_bug: no > hlt_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 mmx fxsr sse > bogomips: 722.94 > > > -- Steve > The cpu does have sep. Is it vanilla kernel? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] remove name length check in a workqueue
On 8/11/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > James Bottomley <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2005-08-10 at 10:37 -0700, Andrew Morton wrote: > > > > and anyway, it doesn't have to be unique; > > > > set_task_comm just does a strlcpy from the name, so it will be truncated > > > > (same as for a binary with > 15 character name). > > > > > > Yup. But it'd be fairly silly to go adding the /%d, only to have it > > > truncated off again. > > > > Well, but the other alternative is that we hit arbitrary BUG_ON() limits > > in systems that create numbered workqueues which is rather contrary to > > our scaleability objectives, isn't it? > > Another alternative is to stop passing in such long strings ;) > > > > What's the actual problem? > > > > What I posted originally; the current SCSI format for a workqueue: > > scsi_wq_%d hits the bug after the host number rises to 100, which has > > been seen by some enterprise person with > 100 HBAs. > > > > The reason for this name is that the error handler thread is called > > scsi_eh_%d; so we could rename all our threads to avoid this, but one > > day someone will come along with a huge enough machine to hit whatever > > limit we squeeze it down to. > > OK, well scsi is using single-threaded workqueues anyway. So we could do: > > if (singlethread) > BUG_ON(strlen(name) > sizeof(task_struct.comm) - 1); > else > BUG_ON(strlen(name) > sizeof(task_struct.comm) - 1 - 4); > > which gets you 10,000,000 HBAs. Enough? > > Ho hum, OK, let's just kill the BUG_ON. s/BUG_ON/WARN_ON/ ? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/11/05, Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote: > > Every interrupt software, or hardware, results in the branched > > procedure being executed with the interrupts OFF. That's why > > one of the first instructions in the kernel entry for a syscall > > is 'sti' to turn them back on. Look at entry.S, line 182. This > > occurs any time a trap occurs as well (Page 26-168, i486 > > Programmer's reference manual). FYI, this is helpful when > > designing/debugging complex interrupt-service routines since > > you can execute the interrupt with a software 'INT' instruction > > (with the correct offset from the IRQ you are using). The software > > doesn't 'know' where the interrupt came from, HW or SW. > > I'm looking at 2.6.13-rc6-git1 line 182 of entry.S and I don't see it. > Must be a different kernel. > > According to the documentation that I was looking at, a trap in x86 does > _not_ turn off interrupts. > ... > > I don't see a sti here. > > -- Steve He is RBJ, Richard B. Johnson, the LKML defacto official troll. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: How to reclaim inode pages on demand
On 8/11/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Magnus Damm <[EMAIL PROTECTED]> wrote: > > > > On 8/11/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Mel Gorman <[EMAIL PROTECTED]> wrote: > > > > The majority of pages I am seeing no longer have page->mapping set. Does > > > > this mean they are in the process of being cleared up? > > > > > > They're just anonymous pages, aren't they? But you said "pages that are > > > being used for inodes". Confused. > > > > I thought page->mapping was used by rmap for both inode-backed and > > anonymous pages. And the PAGE_MAPPING_ANON bit was used to determine > > that page->mapping points to struct anon_vma instead of struct > > address_space. > > > > When is page->mapping NULL? > > > > mm.h:page_mapping() handles all that. at http://sosdg.org/~coywolf/lxr/source/include/linux/mm.h#L561 Should the comment be s/page_mapped/page->mapping/ ? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: How to reclaim inode pages on demand
On 8/11/05, Andrew Morton [EMAIL PROTECTED] wrote: Magnus Damm [EMAIL PROTECTED] wrote: On 8/11/05, Andrew Morton [EMAIL PROTECTED] wrote: Mel Gorman [EMAIL PROTECTED] wrote: The majority of pages I am seeing no longer have page-mapping set. Does this mean they are in the process of being cleared up? They're just anonymous pages, aren't they? But you said pages that are being used for inodes. Confused. I thought page-mapping was used by rmap for both inode-backed and anonymous pages. And the PAGE_MAPPING_ANON bit was used to determine that page-mapping points to struct anon_vma instead of struct address_space. When is page-mapping NULL? mm.h:page_mapping() handles all that. at http://sosdg.org/~coywolf/lxr/source/include/linux/mm.h#L561 Should the comment be s/page_mapped/page-mapping/ ? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/11/05, Steven Rostedt [EMAIL PROTECTED] wrote: On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote: Every interrupt software, or hardware, results in the branched procedure being executed with the interrupts OFF. That's why one of the first instructions in the kernel entry for a syscall is 'sti' to turn them back on. Look at entry.S, line 182. This occurs any time a trap occurs as well (Page 26-168, i486 Programmer's reference manual). FYI, this is helpful when designing/debugging complex interrupt-service routines since you can execute the interrupt with a software 'INT' instruction (with the correct offset from the IRQ you are using). The software doesn't 'know' where the interrupt came from, HW or SW. I'm looking at 2.6.13-rc6-git1 line 182 of entry.S and I don't see it. Must be a different kernel. According to the documentation that I was looking at, a trap in x86 does _not_ turn off interrupts. ... I don't see a sti here. -- Steve He is RBJ, Richard B. Johnson, the LKML defacto official troll. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote: On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote: And booted it. The system is up and running, so I really don't think that the sysenter_entry is used for system calls. Not so Clear as day! And so, looking into sysenter_entry, it seems that my configurations don't seem to use it. This jumps straight to system_call without ever having to turn interrupts on. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 367.939 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 722.94 -- Steve The cpu does have sep. Is it vanilla kernel? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] remove name length check in a workqueue
On 8/11/05, Andrew Morton [EMAIL PROTECTED] wrote: James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2005-08-10 at 10:37 -0700, Andrew Morton wrote: and anyway, it doesn't have to be unique; set_task_comm just does a strlcpy from the name, so it will be truncated (same as for a binary with 15 character name). Yup. But it'd be fairly silly to go adding the /%d, only to have it truncated off again. Well, but the other alternative is that we hit arbitrary BUG_ON() limits in systems that create numbered workqueues which is rather contrary to our scaleability objectives, isn't it? Another alternative is to stop passing in such long strings ;) What's the actual problem? What I posted originally; the current SCSI format for a workqueue: scsi_wq_%d hits the bug after the host number rises to 100, which has been seen by some enterprise person with 100 HBAs. The reason for this name is that the error handler thread is called scsi_eh_%d; so we could rename all our threads to avoid this, but one day someone will come along with a huge enough machine to hit whatever limit we squeeze it down to. OK, well scsi is using single-threaded workqueues anyway. So we could do: if (singlethread) BUG_ON(strlen(name) sizeof(task_struct.comm) - 1); else BUG_ON(strlen(name) sizeof(task_struct.comm) - 1 - 4); which gets you 10,000,000 HBAs. Enough? Ho hum, OK, let's just kill the BUG_ON. s/BUG_ON/WARN_ON/ ? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote: On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote: On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote: And booted it. The system is up and running, so I really don't think that the sysenter_entry is used for system calls. Not so Clear as day! And so, looking into sysenter_entry, it seems that my configurations don't seem to use it. This jumps straight to system_call without ever having to turn interrupts on. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 367.939 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 722.94 -- Steve The cpu does have sep. Is it vanilla kernel? Also glibc support. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Need help in understanding x86 syscall
On 8/12/05, Jeff Carr [EMAIL PROTECTED] wrote: On 08/11/2005 10:18 AM, Steven Rostedt wrote: It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own customizations. But I never touched the sysentry stuff and with a few printks I see it is being initialized. Also glibc support. I'm using Debian unstable with a recent (last week) update. -- Steve But are you using libc6-i686? That enables NPTL. Perhaps the behavior difference is there? I'm surprised int 80 doesn't really cause an interrupt; it doesn't jump to the appropriate place in the x86 vector table? Interesting. Jeff [EMAIL PROTECTED]:~# dpkg -s libc6-i686 ... This set of libraries is optimized for i686 machines, and will only be used if you are running a 2.6 kernel on an i686 class CPU (check the output of `uname -m'). This includes Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezla). . This package includes support for NPTL. . Even with libc6-i686 installed, I can't see sysenter got used. libc6-i686 has /lib/tls/i686/cmov/libc.so.6, not the one /lib/libc-2.3.5.so. mozilla gets: Illegal instruction I've added ud2 in both entry.S and vsyscall-sysenter.S. Any ideas? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: > On 7/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > The patch titled > > > > include/linux/blkdev.h: "extern inline" -> "static inline" > > > > has been added to the -mm tree. Its filename is > > > > include-linux-blkdevh-extern-inline-static-inline.patch > > > > ... > > > > > > > From: Adrian Bunk <[EMAIL PROTECTED]> > > > > "extern inline" doesn't make much sense. > > "extern inline" does make sense, and it does make sense here. please > backout this patch. Hint: the address of block_size() is referenced. > Sorry, I mistook put_int(arg, block_size(bdev)); as address reference. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> The patch titled
>
> include/linux/blkdev.h: "extern inline" -> "static inline"
>
> has been added to the -mm tree. Its filename is
>
> include-linux-blkdevh-extern-inline-static-inline.patch
>
...
>
>
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> "extern inline" doesn't make much sense.
"extern inline" does make sense, and it does make sense here. please
backout this patch. Hint: the address of block_size() is referenced.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> include/linux/blkdev.h |2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN
> include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
> include/linux/blkdev.h
> ---
> devel/include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
> 2005-07-28 19:28:05.0 -0700
> +++ devel-akpm/include/linux/blkdev.h 2005-07-28 19:28:05.0 -0700
> @@ -727,7 +727,7 @@ static inline unsigned int blksize_bits(
> return bits;
> }
>
> -extern inline unsigned int block_size(struct block_device *bdev)
> +static inline unsigned int block_size(struct block_device *bdev)
> {
> return bdev->bd_block_size;
> }
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The patch titled
include/linux/blkdev.h: extern inline - static inline
has been added to the -mm tree. Its filename is
include-linux-blkdevh-extern-inline-static-inline.patch
...
From: Adrian Bunk [EMAIL PROTECTED]
extern inline doesn't make much sense.
extern inline does make sense, and it does make sense here. please
backout this patch. Hint: the address of block_size() is referenced.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/blkdev.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
include/linux/blkdev.h
---
devel/include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
2005-07-28 19:28:05.0 -0700
+++ devel-akpm/include/linux/blkdev.h 2005-07-28 19:28:05.0 -0700
@@ -727,7 +727,7 @@ static inline unsigned int blksize_bits(
return bits;
}
-extern inline unsigned int block_size(struct block_device *bdev)
+static inline unsigned int block_size(struct block_device *bdev)
{
return bdev-bd_block_size;
}
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote: On 7/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The patch titled include/linux/blkdev.h: extern inline - static inline has been added to the -mm tree. Its filename is include-linux-blkdevh-extern-inline-static-inline.patch ... From: Adrian Bunk [EMAIL PROTECTED] extern inline doesn't make much sense. extern inline does make sense, and it does make sense here. please backout this patch. Hint: the address of block_size() is referenced. Sorry, I mistook put_int(arg, block_size(bdev)); as address reference. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] turn many #if $undefined_string into #ifdef $undefined_string
On 7/23/05, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On Fri, 22 Jul 2005 at 16:48:05 +0200, Olaf Hering wrote: > > > turn many #if $undefined_string into #ifdef $undefined_string > > to fix some warnings after -Wno-def was added to global CFLAGS > > > Shouldn't that be "#if defined($undefined_string)"? > > #ifdef is obsolete... > What leads you to believe that? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] turn many #if $undefined_string into #ifdef $undefined_string
On 7/23/05, Chuck Ebbert [EMAIL PROTECTED] wrote: On Fri, 22 Jul 2005 at 16:48:05 +0200, Olaf Hering wrote: turn many #if $undefined_string into #ifdef $undefined_string to fix some warnings after -Wno-def was added to global CFLAGS Shouldn't that be #if defined($undefined_string)? #ifdef is obsolete... What leads you to believe that? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] kbuild: make help binrpm-pkg fix
On Tue, Jul 19, 2005 at 10:21:30PM +0800, Coywolf Qi Hunt wrote: > On 7/15/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > Changes since 2.6.13-rc2-mm2: > > > > > > git-drm.patch > > git-audit.patch > > git-input.patch > > git-kbuild.patch > > make help br0ken, missing matching `'' for binrpm-pkg. > This fixes kbuild make help binrpm-pkg missing `''. Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> --- 2.6.13-rc3-mm1-cy/scripts/package/Makefile~binrpm-pkg-fix 2005-07-19 22:25:27.0 +0800 +++ 2.6.13-rc3-mm1-cy/scripts/package/Makefile 2005-07-19 22:25:47.0 +0800 @@ -94,7 +94,7 @@ clean-dirs += $(objtree)/tar-install/ # --- help: @echo ' rpm-pkg - Build the kernel as an RPM package' - @echo ' binrpm-pkg - Build an rpm package containing the compiled kernel + @echo ' binrpm-pkg - Build an rpm package containing the compiled kernel' @echo 'and modules' @echo ' deb-pkg - Build the kernel as an deb package' @echo ' tar-pkg - Build the kernel as an uncompressed tarball' - 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: 2.6.13-rc3-mm1
On 7/15/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Changes since 2.6.13-rc2-mm2: > > > git-drm.patch > git-audit.patch > git-input.patch > git-kbuild.patch make help br0ken, missing matching `'' for binrpm-pkg. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: 2.6.13-rc3-mm1
On 7/15/05, Andrew Morton [EMAIL PROTECTED] wrote: Changes since 2.6.13-rc2-mm2: git-drm.patch git-audit.patch git-input.patch git-kbuild.patch make help br0ken, missing matching `'' for binrpm-pkg. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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] kbuild: make help binrpm-pkg fix
On Tue, Jul 19, 2005 at 10:21:30PM +0800, Coywolf Qi Hunt wrote: On 7/15/05, Andrew Morton [EMAIL PROTECTED] wrote: Changes since 2.6.13-rc2-mm2: git-drm.patch git-audit.patch git-input.patch git-kbuild.patch make help br0ken, missing matching `'' for binrpm-pkg. This fixes kbuild make help binrpm-pkg missing `''. Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- 2.6.13-rc3-mm1-cy/scripts/package/Makefile~binrpm-pkg-fix 2005-07-19 22:25:27.0 +0800 +++ 2.6.13-rc3-mm1-cy/scripts/package/Makefile 2005-07-19 22:25:47.0 +0800 @@ -94,7 +94,7 @@ clean-dirs += $(objtree)/tar-install/ # --- help: @echo ' rpm-pkg - Build the kernel as an RPM package' - @echo ' binrpm-pkg - Build an rpm package containing the compiled kernel + @echo ' binrpm-pkg - Build an rpm package containing the compiled kernel' @echo 'and modules' @echo ' deb-pkg - Build the kernel as an deb package' @echo ' tar-pkg - Build the kernel as an uncompressed tarball' - 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] add copy_to_user result check
hello, GCC warns me this problem. This patch adds copy_to_user result check in sys_select() and sys_pselect7(). Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> --- diff -pruN 2.6.13-rc3-mm1/fs/select.c 2.6.13-rc3-mm1-cy1/fs/select.c --- 2.6.13-rc3-mm1/fs/select.c 2005-07-15 23:51:35.0 +0800 +++ 2.6.13-rc3-mm1-cy1/fs/select.c 2005-07-17 16:26:58.0 +0800 @@ -401,7 +401,8 @@ asmlinkage long sys_select(int n, fd_set tv.tv_sec++; tv.tv_usec -= 100; } - copy_to_user(tvp, , sizeof(tv)); + if (copy_to_user(tvp, , sizeof(tv))) + return -EFAULT; } return ret; @@ -459,7 +460,8 @@ asmlinkage long sys_pselect7(int n, fd_s ts.tv_sec++; ts.tv_nsec -= 10; } - copy_to_user(tsp, , sizeof(ts)); + if (copy_to_user(tsp, , sizeof(ts))) + return -EFAULT; } if (sigmask) - 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] add copy_to_user result check
hello, GCC warns me this problem. This patch adds copy_to_user result check in sys_select() and sys_pselect7(). Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- diff -pruN 2.6.13-rc3-mm1/fs/select.c 2.6.13-rc3-mm1-cy1/fs/select.c --- 2.6.13-rc3-mm1/fs/select.c 2005-07-15 23:51:35.0 +0800 +++ 2.6.13-rc3-mm1-cy1/fs/select.c 2005-07-17 16:26:58.0 +0800 @@ -401,7 +401,8 @@ asmlinkage long sys_select(int n, fd_set tv.tv_sec++; tv.tv_usec -= 100; } - copy_to_user(tvp, tv, sizeof(tv)); + if (copy_to_user(tvp, tv, sizeof(tv))) + return -EFAULT; } return ret; @@ -459,7 +460,8 @@ asmlinkage long sys_pselect7(int n, fd_s ts.tv_sec++; ts.tv_nsec -= 10; } - copy_to_user(tsp, ts, sizeof(ts)); + if (copy_to_user(tsp, ts, sizeof(ts))) + return -EFAULT; } if (sigmask) - 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: halt: init exits/panic
On 7/9/05, Nico Schottelius <[EMAIL PROTECTED]> wrote: > Hello! > > What's the 'correct behaviour' of an init system, if someone wants > to shutdown the system? > > I currently do: > > - call reboot(RB_POWER_OFF/RB_AUTOBOOT/RB_HALT_SYSTEM) > - _exit(0) > > Is this exit() call wrong? If I do RB_HALT_SYSTEM and _exit(0) after, > the kernel panics. What the panic shows? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: halt: init exits/panic
On 7/9/05, Nico Schottelius [EMAIL PROTECTED] wrote: Hello! What's the 'correct behaviour' of an init system, if someone wants to shutdown the system? I currently do: - call reboot(RB_POWER_OFF/RB_AUTOBOOT/RB_HALT_SYSTEM) - _exit(0) Is this exit() call wrong? If I do RB_HALT_SYSTEM and _exit(0) after, the kernel panics. What the panic shows? -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Swap partition vs swap file
On 7/8/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > Mike Richards <[EMAIL PROTECTED]> wrote: > > > > > > Given this situation, is there any significant performance or > > > > stability advantage to using a swap partition instead of a swap file? > > > > > > In 2.6 they have the same reliability and they will have the same > > > performance unless the swapfile is badly fragmented. > > > > Thanks for the reply -- that's been bugging me for a while now. There > > are a lot of different opinions on the net, and most of the > > conventional wisdom says use a partition instead of a file. It's nice > > to hear from an expert on the matter. > > > > Three more short questions if you have time: > > > > 1. You specify kernel 2.6 -- What about kernel 2.4? How less reliable > > or worse performing is a swapfile on 2.4? > > 2.4 is weaker: it has to allocate memory from the main page allocator when > performing swapout. 2.6 avoids that. > > > 2. Is it possible for the swapfile to become fragmented over time, or > > does it just keep using the same blocks over and over? i.e. if it's > > all contiguous when you first create the swapfile, will it stay that > > way for the life of the file? > > The latter. Create the swapfile when the filesystem is young and empty, I guess/hope dd always makes it contiguously. > it'll be nice and contiguous. Once created the kernel will never add or > remove blocks. The kernel won't let you use a sparse file for a swapfile. > -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Swap partition vs swap file
On 7/8/05, Andrew Morton [EMAIL PROTECTED] wrote: Mike Richards [EMAIL PROTECTED] wrote: Given this situation, is there any significant performance or stability advantage to using a swap partition instead of a swap file? In 2.6 they have the same reliability and they will have the same performance unless the swapfile is badly fragmented. Thanks for the reply -- that's been bugging me for a while now. There are a lot of different opinions on the net, and most of the conventional wisdom says use a partition instead of a file. It's nice to hear from an expert on the matter. Three more short questions if you have time: 1. You specify kernel 2.6 -- What about kernel 2.4? How less reliable or worse performing is a swapfile on 2.4? 2.4 is weaker: it has to allocate memory from the main page allocator when performing swapout. 2.6 avoids that. 2. Is it possible for the swapfile to become fragmented over time, or does it just keep using the same blocks over and over? i.e. if it's all contiguous when you first create the swapfile, will it stay that way for the life of the file? The latter. Create the swapfile when the filesystem is young and empty, I guess/hope dd always makes it contiguously. it'll be nice and contiguous. Once created the kernel will never add or remove blocks. The kernel won't let you use a sparse file for a swapfile. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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 to create sysfs char device nodes
On 6/9/05, Paolo Galtieri <[EMAIL PROTECTED]> wrote: > Hi, > with DEVFS going away I discovered that no character device nodes are > created if a flash device is present which contains filesystems. The > mtd-utils package requires the existence of character device nodes for > performing erase, lock and unlock functions. The problem is that the > flash device driver has not been modified to use sysfs instead of devfs. > > I have attached a patch to mtdchar.c which uses the sysfs interface to > create the appropriate nodes. Please let me know if you have comments. I encountered the same problem days ago. Thanks for the patch. A patch based on yours will be sent in the next mail. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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 to create sysfs char device nodes
On 6/9/05, Paolo Galtieri [EMAIL PROTECTED] wrote: Hi, with DEVFS going away I discovered that no character device nodes are created if a flash device is present which contains filesystems. The mtd-utils package requires the existence of character device nodes for performing erase, lock and unlock functions. The problem is that the flash device driver has not been modified to use sysfs instead of devfs. I have attached a patch to mtdchar.c which uses the sysfs interface to create the appropriate nodes. Please let me know if you have comments. I encountered the same problem days ago. Thanks for the patch. A patch based on yours will be sent in the next mail. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - 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: Kernel module_list
On Thu, Apr 14, 2005 at 08:48:42PM +, Allison wrote: > I am trying to simply print out the module names and code sizes. > I am just learning how to rtraverse these data structures. Just read /proc/modules Coywolf > > Also, on what basis is the decision made whether to export a symbol or not ? > > thanks, > Allison > > Arjan van de Ven wrote: > > On Thu, 2005-04-14 at 19:53 +, Allison wrote: > > > > > > I am trying to access the module list kernel data structure from a > > > kernel module. If I gather correctly, module_list is the symbol that > > > is the head pointer of this list. > > > > can you explain what you want to do with this symbol ? > > > > > > - 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: Kernel messages
On 4/14/05, Iwan Sanders <[EMAIL PROTECTED]> wrote: > Can someone explain to me what just happend? I would really like to know > :-) > I think that the machine ran out of memory and the OOM killer shot some > processes, this is what I found > in my logfiles: > > 1 Time(s): Active:48588 inactive:152 dirty:0 writeback:7 unstable:0 free:502 > slab:13664 mapped:48620 pagetables:325 > 1 Time(s): DMA free:1008kB min:28kB low:56kB high:84kB active:7364kB > inactive:0kB present:16384kB > 1 Time(s): DMA per-cpu: > 1 Time(s): DMA: 0*4kB 0*8kB 1*16kB 7*32kB 4*64kB 0*128kB 0*256kB 1*512kB > 0*1024kB 0*2048kB 0*4096kB = 1008kB > 1 Time(s): Free pages:2008kB (0kB HighMem) > 1 Time(s): HighMem free:0kB min:128kB low:256kB high:384kB active:0kB > inactive:0kB present:0kB > 1 Time(s): HighMem per-cpu: empty > 1 Time(s): HighMem: empty > 1 Time(s): Normal free:1000kB min:476kB low:952kB high:1428kB active:186988kB > inactive:608kB present:245120kB > 1 Time(s): Normal per-cpu: > 1 Time(s): Normal: 14*4kB 2*8kB 0*16kB 1*32kB 2*64kB 0*128kB 1*256kB 1*512kB > 0*1024kB 0*2048kB 0*4096kB = 1000kB > 1 Time(s): Swap cache: add 0, delete 0, find 0/0, race 0+0 > 1 Time(s): cpu 0 cold: low 0, high 2, batch 1 > 1 Time(s): cpu 0 cold: low 0, high 28, batch 14 > 1 Time(s): cpu 0 hot: low 2, high 6, batch 1 > 1 Time(s): cpu 0 hot: low 28, high 84, batch 14 > 1 Time(s): oom-killer: gfp_mask=0x1d2 > 1 Time(s): protections[]: 0 0 0 > 1 Time(s): protections[]: 0 238 238 > 1 Time(s): protections[]: 14 252 252 > > Cheers, > > Iwan Sanders > Yes, oom, and your kernel is a bit old. -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Kernel messages
On 4/14/05, Iwan Sanders [EMAIL PROTECTED] wrote: Can someone explain to me what just happend? I would really like to know :-) I think that the machine ran out of memory and the OOM killer shot some processes, this is what I found in my logfiles: 1 Time(s): Active:48588 inactive:152 dirty:0 writeback:7 unstable:0 free:502 slab:13664 mapped:48620 pagetables:325 1 Time(s): DMA free:1008kB min:28kB low:56kB high:84kB active:7364kB inactive:0kB present:16384kB 1 Time(s): DMA per-cpu: 1 Time(s): DMA: 0*4kB 0*8kB 1*16kB 7*32kB 4*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1008kB 1 Time(s): Free pages:2008kB (0kB HighMem) 1 Time(s): HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB 1 Time(s): HighMem per-cpu: empty 1 Time(s): HighMem: empty 1 Time(s): Normal free:1000kB min:476kB low:952kB high:1428kB active:186988kB inactive:608kB present:245120kB 1 Time(s): Normal per-cpu: 1 Time(s): Normal: 14*4kB 2*8kB 0*16kB 1*32kB 2*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1000kB 1 Time(s): Swap cache: add 0, delete 0, find 0/0, race 0+0 1 Time(s): cpu 0 cold: low 0, high 2, batch 1 1 Time(s): cpu 0 cold: low 0, high 28, batch 14 1 Time(s): cpu 0 hot: low 2, high 6, batch 1 1 Time(s): cpu 0 hot: low 28, high 84, batch 14 1 Time(s): oom-killer: gfp_mask=0x1d2 1 Time(s): protections[]: 0 0 0 1 Time(s): protections[]: 0 238 238 1 Time(s): protections[]: 14 252 252 Cheers, Iwan Sanders Yes, oom, and your kernel is a bit old. -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Kernel module_list
On Thu, Apr 14, 2005 at 08:48:42PM +, Allison wrote: I am trying to simply print out the module names and code sizes. I am just learning how to rtraverse these data structures. Just read /proc/modules Coywolf Also, on what basis is the decision made whether to export a symbol or not ? thanks, Allison Arjan van de Ven wrote: On Thu, 2005-04-14 at 19:53 +, Allison wrote: I am trying to access the module list kernel data structure from a kernel module. If I gather correctly, module_list is the symbol that is the head pointer of this list. can you explain what you want to do with this symbol ? - 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 006/198] arm: add comment about max_low_pfn/max_pfn
FYI http://lkml.org/lkml/2004/6/29/57 On 4/13/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: > I told rmk about this long time ago. > > On 4/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > From: Russell King <[EMAIL PROTECTED]> > > > > Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, > > rather than the maximum PFN on ARM. This doesn't seem to cause any > > problems, > > so just add a note about it. > > > > Signed-off-by: Russell King <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > 25-akpm/arch/arm/mm/init.c |3 +++ > > 1 files changed, 3 insertions(+) > > > > diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > > arch/arm/mm/init.c > > --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > > 2005-04-12 03:21:04.967381744 -0700 > > +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 > > @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi > > * This doesn't seem to be used by the Linux memory > > * manager any more. If we can get rid of it, we > > * also get rid of some of the stuff above as well. > > +* > > +* Note: max_low_pfn and max_pfn reflect the number > > +* of _pages_ in the system, not the maximum PFN. > > */ > > max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > > max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > > _ > > -- > Coywolf Qi Hunt > http://sosdg.org/~coywolf/ > -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 006/198] arm: add comment about max_low_pfn/max_pfn
I told rmk about this long time ago. On 4/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > From: Russell King <[EMAIL PROTECTED]> > > Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, > rather than the maximum PFN on ARM. This doesn't seem to cause any problems, > so just add a note about it. > > Signed-off-by: Russell King <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- > > 25-akpm/arch/arm/mm/init.c |3 +++ > 1 files changed, 3 insertions(+) > > diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > arch/arm/mm/init.c > --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn > 2005-04-12 03:21:04.967381744 -0700 > +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 > @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi > * This doesn't seem to be used by the Linux memory > * manager any more. If we can get rid of it, we > * also get rid of some of the stuff above as well. > +* > +* Note: max_low_pfn and max_pfn reflect the number > +* of _pages_ in the system, not the maximum PFN. > */ > max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); > _ -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 006/198] arm: add comment about max_low_pfn/max_pfn
I told rmk about this long time ago. On 4/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Russell King [EMAIL PROTECTED] Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, rather than the maximum PFN on ARM. This doesn't seem to cause any problems, so just add a note about it. Signed-off-by: Russell King [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- 25-akpm/arch/arm/mm/init.c |3 +++ 1 files changed, 3 insertions(+) diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn arch/arm/mm/init.c --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn 2005-04-12 03:21:04.967381744 -0700 +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi * This doesn't seem to be used by the Linux memory * manager any more. If we can get rid of it, we * also get rid of some of the stuff above as well. +* +* Note: max_low_pfn and max_pfn reflect the number +* of _pages_ in the system, not the maximum PFN. */ max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); _ -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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 006/198] arm: add comment about max_low_pfn/max_pfn
FYI http://lkml.org/lkml/2004/6/29/57 On 4/13/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote: I told rmk about this long time ago. On 4/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Russell King [EMAIL PROTECTED] Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, rather than the maximum PFN on ARM. This doesn't seem to cause any problems, so just add a note about it. Signed-off-by: Russell King [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- 25-akpm/arch/arm/mm/init.c |3 +++ 1 files changed, 3 insertions(+) diff -puN arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn arch/arm/mm/init.c --- 25/arch/arm/mm/init.c~arm-add-comment-about-max_low_pfn-max_pfn 2005-04-12 03:21:04.967381744 -0700 +++ 25-akpm/arch/arm/mm/init.c 2005-04-12 03:21:04.971381136 -0700 @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi * This doesn't seem to be used by the Linux memory * manager any more. If we can get rid of it, we * also get rid of some of the stuff above as well. +* +* Note: max_low_pfn and max_pfn reflect the number +* of _pages_ in the system, not the maximum PFN. */ max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); _ -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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] reparent_to_init-cleanup
Hello,
Split out from my oom-killer patch, this patch hides reparent_to_init().
reparent_to_init()
should only be called by daemonize(). This applies to 2.6.12-rc2-mm2 too.
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
arch/i386/mach-voyager/voyager_thread.c |1 -
include/linux/sched.h |1 -
kernel/exit.c |2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
diff -pruN 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c
2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c
--- 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c 2004-08-20
14:39:58.0 +0800
+++ 2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c 2005-04-08
18:53:06.0 +0800
@@ -126,7 +126,6 @@ thread(void *unused)
kvoyagerd_running = 1;
- reparent_to_init();
daemonize(THREAD_NAME);
set_timeout = 0;
diff -pruN 2.6.12-rc2-mm1/include/linux/sched.h
2.6.12-rc2-mm1-cy/include/linux/sched.h
--- 2.6.12-rc2-mm1/include/linux/sched.h2005-04-06 10:18:18.0
+0800
+++ 2.6.12-rc2-mm1-cy/include/linux/sched.h 2005-04-08 18:53:06.0
+0800
@@ -1068,7 +1068,6 @@ extern void exit_itimers(struct signal_s
extern NORET_TYPE void do_group_exit(int);
-extern void reparent_to_init(void);
extern void daemonize(const char *, ...);
extern int allow_signal(int);
extern int disallow_signal(int);
diff -pruN 2.6.12-rc2-mm1/kernel/exit.c 2.6.12-rc2-mm1-cy/kernel/exit.c
--- 2.6.12-rc2-mm1/kernel/exit.c2005-04-06 10:18:20.0 +0800
+++ 2.6.12-rc2-mm1-cy/kernel/exit.c 2005-04-08 18:53:06.0 +0800
@@ -224,7 +224,7 @@ static inline int has_stopped_jobs(int p
*
* NOTE that reparent_to_init() gives the caller full capabilities.
*/
-void reparent_to_init(void)
+static inline void reparent_to_init(void)
{
write_lock_irq(_lock);
-
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] reparent_to_init-cleanup
Hello,
Split out from my oom-killer patch, this patch hides reparent_to_init().
reparent_to_init()
should only be called by daemonize(). This applies to 2.6.12-rc2-mm2 too.
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
arch/i386/mach-voyager/voyager_thread.c |1 -
include/linux/sched.h |1 -
kernel/exit.c |2 +-
3 files changed, 1 insertion(+), 3 deletions(-)
diff -pruN 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c
2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c
--- 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c 2004-08-20
14:39:58.0 +0800
+++ 2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c 2005-04-08
18:53:06.0 +0800
@@ -126,7 +126,6 @@ thread(void *unused)
kvoyagerd_running = 1;
- reparent_to_init();
daemonize(THREAD_NAME);
set_timeout = 0;
diff -pruN 2.6.12-rc2-mm1/include/linux/sched.h
2.6.12-rc2-mm1-cy/include/linux/sched.h
--- 2.6.12-rc2-mm1/include/linux/sched.h2005-04-06 10:18:18.0
+0800
+++ 2.6.12-rc2-mm1-cy/include/linux/sched.h 2005-04-08 18:53:06.0
+0800
@@ -1068,7 +1068,6 @@ extern void exit_itimers(struct signal_s
extern NORET_TYPE void do_group_exit(int);
-extern void reparent_to_init(void);
extern void daemonize(const char *, ...);
extern int allow_signal(int);
extern int disallow_signal(int);
diff -pruN 2.6.12-rc2-mm1/kernel/exit.c 2.6.12-rc2-mm1-cy/kernel/exit.c
--- 2.6.12-rc2-mm1/kernel/exit.c2005-04-06 10:18:20.0 +0800
+++ 2.6.12-rc2-mm1-cy/kernel/exit.c 2005-04-08 18:53:06.0 +0800
@@ -224,7 +224,7 @@ static inline int has_stopped_jobs(int p
*
* NOTE that reparent_to_init() gives the caller full capabilities.
*/
-void reparent_to_init(void)
+static inline void reparent_to_init(void)
{
write_lock_irq(tasklist_lock);
-
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: 2.6.12-rc1-mm4
Andrew Morton wrote: ... make-sysrq-f-call-oom_kill.patch make sysrq-F call oom_kill() Glad to see it fixed. :) - 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: 2.6.12-rc1-mm4
Andrew Morton wrote: ... make-sysrq-f-call-oom_kill.patch make sysrq-F call oom_kill() Glad to see it fixed. :) - 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] oom lca -- fork bombing killer
Andrew Morton wrote:
Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
Linux OOM LCA (Least Common Ancestor) Patch
...
--- 2.6.12-rc1-mm3/include/linux/sched.h 2005-03-26 13:21:11.0 +0800
+++ 2.6.12-rc1-mm3-cy/include/linux/sched.h 2005-03-28 10:18:24.0 +0800
@@ -656,11 +656,7 @@ struct task_struct {
unsigned did_exec:1;
pid_t pid;
pid_t tgid;
- /*
- * pointers to (original) parent process, youngest child, younger sibling,
- * older sibling, respectively. (p->father can be replaced with
- * p->parent->pid)
- */
+
struct task_struct *real_parent; /* real parent process (when being debugged) */
struct task_struct *parent; /* parent process */
/*
@@ -669,6 +665,9 @@ struct task_struct {
*/
struct list_head children; /* list of my children */
struct list_head sibling; /* linkage in my parent's children list */
+ struct task_struct *bio_parent;
+ struct list_head bio_children;
+ struct list_head bio_sibling;
struct task_struct *group_leader; /* threadgroup leader */
/* PID/PID hash table linkage. */
Well that was a bit cruel - it would have been better to fix up the comment
rather than deleting it. And to have documented the newly-added fields.
There used to have struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr,
*p_osptr;
They've all disappeared in 2.6. That comment is about that.
(The bio_* names remind me of fs/bio.c. Maybe rename them to initial_*?)
biological parent, bio_parent. It makes sense, so basically.
@@ -1068,7 +1067,6 @@ extern void exit_itimers(struct signal_s
extern NORET_TYPE void do_group_exit(int);
-extern void reparent_to_init(void);
OK, but the reparent_to_init() cleanup should be a separate patch, please.
static inline void reparent_thread(task_t *p, task_t *father, int traced)
@@ -590,6 +596,7 @@ static inline void reparent_thread(task_
static inline void forget_original_parent(struct task_struct * father,
struct list_head *to_release)
{
+ extern struct task_struct *last_chosen_parent;
This declaration should be in a header file.
+
+ list_for_each_safe(_p, _n, >bio_children) {
+ p = list_entry(_p, struct task_struct, bio_sibling);
+ list_del_init(>bio_sibling);
+ p->bio_parent = father->bio_parent;
+ list_add_tail(>bio_sibling, &(p->bio_parent)->bio_children);
+ }
This big list walk on the exit path might be unpopular from a performance
and latency POV.
There are already two other list walks. This one isn't much bigger.
It's unavoidable in normal process exits. But it could be avoided during oom
killing by always killing leaves.
/*
+ * LCA: Least Common Ancestor
+ *
+ * Returns NULL if no LCA (LCA is init_task)
+ *
+ * I prefer to use task_t for function parameters, and
+ * struct task_struct elsewhere. -- coywolf
+ */
Most other people prefer to not use the typedef...
+static struct task_struct * find_lca(task_t *p1, task_t *p2)
+{
+ struct task_struct *tsk1, *tsk2;
+
+ for (tsk1 = p1; tsk1 != _task; tsk1 = tsk1->bio_parent) {
+ for (tsk2 = p2; tsk2 != _task; tsk2 = tsk2->bio_parent)
+ if (tsk1 == tsk2)
+ return tsk1;
+ }
+
+ return NULL;
+}
eep. That's an O(n^2) search? What does it do with 5 tasks?
Two levels 5 loops cost 4.6 seconds on my 2.4G celeron.
Yes, I'll improve it to O(n).
- struct task_struct *c;
- struct list_head *tsk;
+ if (list_empty(>bio_children)) {
+ mmput(mm);
+ __oom_kill_task(p);
+ return 1;
+ }
- /* Try to kill a child first */
- list_for_each(tsk, >children) {
- c = list_entry(tsk, struct task_struct, sibling);
- if (c->mm == p->mm)
- continue;
- mm = oom_kill_task(c);
- if (mm)
- return mm;
+ /* Kill all descendants */
+ for_each_process(q) {
+ if (q->pid > 1) {
+ if (test_tsk_thread_flag(q, TIF_MEMDIE) ||
+ (q->flags & PF_EXITING) || (q->flags & PF_DEAD))
+ continue;
+ if (is_ancestor(p, q))
+ __oom_kill_task(q);
+ }
}
That's O(n^2) too.
I'm working on it. It'll be O(n), and no extra memory allocations even.
The biggest problem is when swapping is on, it doesn't help much.
Swapping needs similiar control too. Let's do things one by one.
Coywolf
-
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] oom lca -- fork bombing killer
Andrew Morton wrote:
Coywolf Qi Hunt [EMAIL PROTECTED] wrote:
Linux OOM LCA (Least Common Ancestor) Patch
...
--- 2.6.12-rc1-mm3/include/linux/sched.h 2005-03-26 13:21:11.0 +0800
+++ 2.6.12-rc1-mm3-cy/include/linux/sched.h 2005-03-28 10:18:24.0 +0800
@@ -656,11 +656,7 @@ struct task_struct {
unsigned did_exec:1;
pid_t pid;
pid_t tgid;
- /*
- * pointers to (original) parent process, youngest child, younger sibling,
- * older sibling, respectively. (p-father can be replaced with
- * p-parent-pid)
- */
+
struct task_struct *real_parent; /* real parent process (when being debugged) */
struct task_struct *parent; /* parent process */
/*
@@ -669,6 +665,9 @@ struct task_struct {
*/
struct list_head children; /* list of my children */
struct list_head sibling; /* linkage in my parent's children list */
+ struct task_struct *bio_parent;
+ struct list_head bio_children;
+ struct list_head bio_sibling;
struct task_struct *group_leader; /* threadgroup leader */
/* PID/PID hash table linkage. */
Well that was a bit cruel - it would have been better to fix up the comment
rather than deleting it. And to have documented the newly-added fields.
There used to have struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr,
*p_osptr;
They've all disappeared in 2.6. That comment is about that.
(The bio_* names remind me of fs/bio.c. Maybe rename them to initial_*?)
biological parent, bio_parent. It makes sense, so basically.
@@ -1068,7 +1067,6 @@ extern void exit_itimers(struct signal_s
extern NORET_TYPE void do_group_exit(int);
-extern void reparent_to_init(void);
OK, but the reparent_to_init() cleanup should be a separate patch, please.
static inline void reparent_thread(task_t *p, task_t *father, int traced)
@@ -590,6 +596,7 @@ static inline void reparent_thread(task_
static inline void forget_original_parent(struct task_struct * father,
struct list_head *to_release)
{
+ extern struct task_struct *last_chosen_parent;
This declaration should be in a header file.
+
+ list_for_each_safe(_p, _n, father-bio_children) {
+ p = list_entry(_p, struct task_struct, bio_sibling);
+ list_del_init(p-bio_sibling);
+ p-bio_parent = father-bio_parent;
+ list_add_tail(p-bio_sibling, (p-bio_parent)-bio_children);
+ }
This big list walk on the exit path might be unpopular from a performance
and latency POV.
There are already two other list walks. This one isn't much bigger.
It's unavoidable in normal process exits. But it could be avoided during oom
killing by always killing leaves.
/*
+ * LCA: Least Common Ancestor
+ *
+ * Returns NULL if no LCA (LCA is init_task)
+ *
+ * I prefer to use task_t for function parameters, and
+ * struct task_struct elsewhere. -- coywolf
+ */
Most other people prefer to not use the typedef...
+static struct task_struct * find_lca(task_t *p1, task_t *p2)
+{
+ struct task_struct *tsk1, *tsk2;
+
+ for (tsk1 = p1; tsk1 != init_task; tsk1 = tsk1-bio_parent) {
+ for (tsk2 = p2; tsk2 != init_task; tsk2 = tsk2-bio_parent)
+ if (tsk1 == tsk2)
+ return tsk1;
+ }
+
+ return NULL;
+}
eep. That's an O(n^2) search? What does it do with 5 tasks?
Two levels 5 loops cost 4.6 seconds on my 2.4G celeron.
Yes, I'll improve it to O(n).
- struct task_struct *c;
- struct list_head *tsk;
+ if (list_empty(p-bio_children)) {
+ mmput(mm);
+ __oom_kill_task(p);
+ return 1;
+ }
- /* Try to kill a child first */
- list_for_each(tsk, p-children) {
- c = list_entry(tsk, struct task_struct, sibling);
- if (c-mm == p-mm)
- continue;
- mm = oom_kill_task(c);
- if (mm)
- return mm;
+ /* Kill all descendants */
+ for_each_process(q) {
+ if (q-pid 1) {
+ if (test_tsk_thread_flag(q, TIF_MEMDIE) ||
+ (q-flags PF_EXITING) || (q-flags PF_DEAD))
+ continue;
+ if (is_ancestor(p, q))
+ __oom_kill_task(q);
+ }
}
That's O(n^2) too.
I'm working on it. It'll be O(n), and no extra memory allocations even.
The biggest problem is when swapping is on, it doesn't help much.
Swapping needs similiar control too. Let's do things one by one.
Coywolf
-
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: Can't use SYSFS for "Proprietry" driver modules !!!.
Lee Revell wrote: On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote: On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: I am writing a "Proprietry" driver module for a "Proprietry" PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. What ever gave you the impression that it was legal to create a "Proprietry" kernel driver for Linux in the first place. The fact that Nvidia and ATI get away with it? I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1. $ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/ Makefile@makedevices.sh* nv-vm.c nv_compiler.h os-agp.c os-registry.c Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h os-registry.o Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o pat.h README nv-linux.h nv.c nvidia.mod.o os-interface.c precompiled/ conftest.sh nv-memdbg.h nv.h nvidia.o os-interface.h rmretval.h gcc-version-check.c nv-misc.hnv.o nvtypes.h os-interface.o So it seems nvidia has their kernel module `open'. Is it? Coywolf - 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: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 15:04:16 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > * Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: > > On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > > > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > > > And happy easter to you all. Just got this while trying to delete some > > > > files on my system. > > > > > > I'm curious, what was the virtual address the kernel was "Unable to > > > handle..." > > > That part was left off this bug report. > > > > > > > : printing eip: > > > > : c021f089 > > > > : *pde = > > > > : Oops: [#1] > > > > : PREEMPT > > > > : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth > > > > snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 > > > > snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer > > > > snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp > > > > parport 8139too mii crc32 > > > > : CPU:0 > > > > : EIP:0060:[linvfs_open+89/160]Not tainted VLI > > > > : EFLAGS: 00010282 (2.6.11.6) > > > > : EIP is at linvfs_open+0x59/0xa0 > > > > > > Nothing in the -stable series has changed either XFS or the core vfs > > > path on during file open. Without a chance of reproducing or any more > > > information, it'll be tough to make much progress here. > > > > > > > : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 > > > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > > > : ds: 007b es: 007b ss: 0068 > > > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > > > d73504c0 > > > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > > > cbcdff54 > > > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > > > 0031 > > > > : Call Trace: > > > > : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 > > > > : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 > > > > : [filp_open+92/112] filp_open+0x5c/0x70 > > > > : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 > > > > : [sys_open+73/144] sys_open+0x49/0x90 > > > > : [syscall_call+7/11] syscall_call+0x7/0xb > > > > : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 > > > > 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 <8b> > > > > 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 > > > > > > Best I can tell, you hit this: > > > > > > mov0x8(%eax),%edx > > > > > > with eax == . This corresponds to a vp->v_fops (or rather > > > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > > > NULL v_bh.bh_first (which looks like it's meant to be used to mean > > > uninitialized). May check with XFS folks if they've seen this type > > > of bug. > > > > I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an > > invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address > > f. > > eax == 0 is to clear the memory in memset(). > > The trace indicates it's in linvfs_open > (EIP: 0060:[linvfs_open+89/160]) > and the insturction dump at the end supports that. How to explain: Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Thanks -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright <[EMAIL PROTECTED]> wrote: > * Ali Akcaagac ([EMAIL PROTECTED]) wrote: > > And happy easter to you all. Just got this while trying to delete some > > files on my system. > > I'm curious, what was the virtual address the kernel was "Unable to handle..." > That part was left off this bug report. > > > : printing eip: > > : c021f089 > > : *pde = > > : Oops: [#1] > > : PREEMPT > > : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth > > snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 > > snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer > > snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp > > parport 8139too mii crc32 > > : CPU:0 > > : EIP:0060:[linvfs_open+89/160]Not tainted VLI > > : EFLAGS: 00010282 (2.6.11.6) > > : EIP is at linvfs_open+0x59/0xa0 > > Nothing in the -stable series has changed either XFS or the core vfs > path on during file open. Without a chance of reproducing or any more > information, it'll be tough to make much progress here. > > > : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 > > : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 > > : ds: 007b es: 007b ss: 0068 > > : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) > > : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c > > d73504c0 > > :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c > > cbcdff54 > > :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 > > 0031 > > : Call Trace: > > : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 > > : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 > > : [filp_open+92/112] filp_open+0x5c/0x70 > > : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 > > : [sys_open+73/144] sys_open+0x49/0x90 > > : [syscall_call+7/11] syscall_call+0x7/0xb > > : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 > > 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 <8b> > > 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 > > Best I can tell, you hit this: > > mov0x8(%eax),%edx > > with eax == . This corresponds to a vp->v_fops (or rather > vp->v_bh.bh_first->bd_ops) deref. So, looks like the vnode has a > NULL v_bh.bh_first (which looks like it's meant to be used to mean > uninitialized). May check with XFS folks if they've seen this type > of bug. I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. eax == 0 is to clear the memory in memset(). -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright [EMAIL PROTECTED] wrote: * Ali Akcaagac ([EMAIL PROTECTED]) wrote: And happy easter to you all. Just got this while trying to delete some files on my system. I'm curious, what was the virtual address the kernel was Unable to handle... That part was left off this bug report. : printing eip: : c021f089 : *pde = : Oops: [#1] : PREEMPT : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp parport 8139too mii crc32 : CPU:0 : EIP:0060:[linvfs_open+89/160]Not tainted VLI : EFLAGS: 00010282 (2.6.11.6) : EIP is at linvfs_open+0x59/0xa0 Nothing in the -stable series has changed either XFS or the core vfs path on during file open. Without a chance of reproducing or any more information, it'll be tough to make much progress here. : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 : ds: 007b es: 007b ss: 0068 : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c d73504c0 :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c cbcdff54 :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 0031 : Call Trace: : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 : [filp_open+92/112] filp_open+0x5c/0x70 : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 : [sys_open+73/144] sys_open+0x49/0x90 : [syscall_call+7/11] syscall_call+0x7/0xb : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 8b 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 Best I can tell, you hit this: mov0x8(%eax),%edx with eax == . This corresponds to a vp-v_fops (or rather vp-v_bh.bh_first-bd_ops) deref. So, looks like the vnode has a NULL v_bh.bh_first (which looks like it's meant to be used to mean uninitialized). May check with XFS folks if they've seen this type of bug. I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. eax == 0 is to clear the memory in memset(). -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Kernel OOOPS in 2.6.11.6
On Mon, 28 Mar 2005 15:04:16 -0800, Chris Wright [EMAIL PROTECTED] wrote: * Coywolf Qi Hunt ([EMAIL PROTECTED]) wrote: On Mon, 28 Mar 2005 14:44:30 -0800, Chris Wright [EMAIL PROTECTED] wrote: * Ali Akcaagac ([EMAIL PROTECTED]) wrote: And happy easter to you all. Just got this while trying to delete some files on my system. I'm curious, what was the virtual address the kernel was Unable to handle... That part was left off this bug report. : printing eip: : c021f089 : *pde = : Oops: [#1] : PREEMPT : Modules linked in: snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore parport_pc lp parport 8139too mii crc32 : CPU:0 : EIP:0060:[linvfs_open+89/160]Not tainted VLI : EFLAGS: 00010282 (2.6.11.6) : EIP is at linvfs_open+0x59/0xa0 Nothing in the -stable series has changed either XFS or the core vfs path on during file open. Without a chance of reproducing or any more information, it'll be tough to make much progress here. : eax: ebx: c77ac06c ecx: 0001 edx: c021f030 : esi: edi: c77ac050 ebp: dffe41a0 esp: c2d95f14 : ds: 007b es: 007b ss: 0068 : Process mc (pid: 17862, threadinfo=c2d94000 task=d18d2a80) : Stack: c01561a9 dffe41a0 d73504c0 c77ac06c c015446b c77ac06c d73504c0 :0001 ffe9 8000 8000 dc364000 c2d94000 c015426c cbcdff54 :dffe41a0 8000 c2d95f60 cbcdff54 dffe41a0 bfffeef0 0d00ad72 0031 : Call Trace: : [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 : [dentry_open+491/672] dentry_open+0x1eb/0x2a0 : [filp_open+92/112] filp_open+0x5c/0x70 : [get_unused_fd+123/224] get_unused_fd+0x7b/0xe0 : [sys_open+73/144] sys_open+0x49/0x90 : [syscall_call+7/11] syscall_call+0x7/0xb : Code: 5b 3c b8 01 00 00 00 e8 c6 42 ef ff b8 00 e0 ff ff 21 e0 8b 40 08 a8 08 75 4d 85 f6 7c 0a 7f 32 81 fb ff ff ff 7f 77 2a 8b 47 14 8b 50 08 c7 44 24 04 00 00 00 00 89 04 24 ff 52 04 8b 5c 24 08 Best I can tell, you hit this: mov0x8(%eax),%edx with eax == . This corresponds to a vp-v_fops (or rather vp-v_bh.bh_first-bd_ops) deref. So, looks like the vnode has a NULL v_bh.bh_first (which looks like it's meant to be used to mean uninitialized). May check with XFS folks if they've seen this type of bug. I think it is f = kmem_cache_alloc(filp_cachep, GFP_KERNEL); returns an invalid pointer, then in memset(f, 0, sizeof(*f)); fault happens at address f. eax == 0 is to clear the memory in memset(). The trace indicates it's in linvfs_open (EIP: 0060:[linvfs_open+89/160]) and the insturction dump at the end supports that. How to explain: Call Trace: [get_empty_filp+89/208] get_empty_filp+0x59/0xd0 ? Thanks -- Coywolf Qi Hunt http://sosdg.org/~coywolf/ - 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: Can't use SYSFS for Proprietry driver modules !!!.
Lee Revell wrote: On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote: On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: I am writing a Proprietry driver module for a Proprietry PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. What ever gave you the impression that it was legal to create a Proprietry kernel driver for Linux in the first place. The fact that Nvidia and ATI get away with it? I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1. $ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/ Makefile@makedevices.sh* nv-vm.c nv_compiler.h os-agp.c os-registry.c Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h os-registry.o Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o pat.h README nv-linux.h nv.c nvidia.mod.o os-interface.c precompiled/ conftest.sh nv-memdbg.h nv.h nvidia.o os-interface.h rmretval.h gcc-version-check.c nv-misc.hnv.o nvtypes.h os-interface.o So it seems nvidia has their kernel module `open'. Is it? Coywolf - 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] oom lca -- fork bombing killer
March 28, 2005 Coywolf Qi Hunt [EMAIL PROTECTED] Linux OOM LCA (Least Common Ancestor) Patch An anti Fork Bombing Solution Introduction People complain that linux is still vulnerable to the ancient fork bombing. A quick scratch <http://freeforge.net/~coywolf/oom-bomb/> simply running as normal user could make a linux box totally unusable. Another example is in the recent thread: oom with 2.6.11 <http://lkml.org/lkml/2005/3/17/142> The only way currently to deal with fork bombing is to limit the number of running processes or the forking rate. This patch brings a new way to find out and kill the possible fork bombing processes or any misbehaving processes taking up too much memory. The patch applies to 2.6.12-rc1-mm3 and seems able to kill various fork bombings. Simple Experiment Result It is tested on an 256M desktop box. With swapoff and in console, it works pretty well. After the fork bomber has forked into about 1500 instances, RES = 1036k SHR = 876k 1500*(1036k-876k)=234M it got killed completely. When the fork bomber is running as root, kernel first kills the X server and XFce4 el al, immediately kernel kills the bomb totally too. I haven't tested with swapon yet. The hard disk would keep swapping badly then. When in X, the screen got corrupted, but the box can still reboot through ctrl+alt+del. The oom LCA algorithm details 1. New elements add to struct task_struct : struct task_struct *bio_parent struct list_head bio_children; struct list_head bio_sibling; Adds struct task_struct *bio_parent to struct task_struct. Unlike struct task_struct *parent, user programs can not change it by daemon(3). It is describing the facts except when it is a kernel thread. We don't plan to oom kill any kernel threads. 2. If a process is malicious, we'll consider its children malicious too. So we kill the choose process and all its descendants. This way we'll be far faster than the tumor forking. LCA always grows upwards. 3. LCA(Least Common Ancestor Algorithm, I choose the term LCA for it is more widely used than NCA(Nearest Common Ancestor) according to google.) We remember the last killed process' parent, next time we'll kill the remembered last_chosen_parent and the new worst process(the highest badness)'s least common ancestor. NOTE if find_lca() fails, we just kill the worst process and we must _update_ the last_kill_process to a new value. 4. Calculates oom badness bio_children is considered instead of children. Not quite related changes I also include some other obvious cleanups. They are: 1. hides reparent_to_init(), reparent_to_init() should be called only by daemonize() 2. removes obsolete code comments in task_struct 3. removes an obsolete parameter from choose_new_parent() and cleanups 4. in reparent_thread(), ptrace should be type long, not int. 5. cleanups in mm/oom_kill.c Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> --- arch/i386/mach-voyager/voyager_thread.c |1 include/linux/init_task.h |3 include/linux/sched.h | 10 -- kernel/exit.c | 34 ++- kernel/fork.c |4 mm/oom_kill.c | 141 6 files changed, 129 insertions(+), 64 deletions(-) diff -pruN 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c 2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c --- 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c 2004-08-20 14:39:58.0 +0800 +++ 2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c 2005-03-28 10:18:24.0 +0800 @@ -126,7 +126,6 @@ thread(void *unused) kvoyagerd_running = 1; - reparent_to_init(); daemonize(THREAD_NAME); set_timeout = 0; diff -pruN 2.6.12-rc1-mm3/include/linux/init_task.h 2.6.12-rc1-mm3-cy/include/linux/init_task.h --- 2.6.12-rc1-mm3/include/linux/init_task.h2005-03-26 13:21:10.0 +0800 +++ 2.6.12-rc1-mm3-cy/include/linux/init_task.h 2005-03-28 10:18:24.0 +0800 @@ -90,6 +90,9 @@ extern struct group_info init_groups; .parent = , \ .children = LIST_HEAD_INIT(tsk.children), \ .sibling= LIST_HEAD_INIT(tsk.sibling), \ + .bio_parent = , \ + .bio_children = LIST_HEAD_INIT(tsk.bio_children), \ +
[patch] oom lca -- fork bombing killer
March 28, 2005 Coywolf Qi Hunt [EMAIL PROTECTED] Linux OOM LCA (Least Common Ancestor) Patch An anti Fork Bombing Solution Introduction People complain that linux is still vulnerable to the ancient fork bombing. A quick scratch http://freeforge.net/~coywolf/oom-bomb/ simply running as normal user could make a linux box totally unusable. Another example is in the recent thread: oom with 2.6.11 http://lkml.org/lkml/2005/3/17/142 The only way currently to deal with fork bombing is to limit the number of running processes or the forking rate. This patch brings a new way to find out and kill the possible fork bombing processes or any misbehaving processes taking up too much memory. The patch applies to 2.6.12-rc1-mm3 and seems able to kill various fork bombings. Simple Experiment Result It is tested on an 256M desktop box. With swapoff and in console, it works pretty well. After the fork bomber has forked into about 1500 instances, RES = 1036k SHR = 876k 1500*(1036k-876k)=234M it got killed completely. When the fork bomber is running as root, kernel first kills the X server and XFce4 el al, immediately kernel kills the bomb totally too. I haven't tested with swapon yet. The hard disk would keep swapping badly then. When in X, the screen got corrupted, but the box can still reboot through ctrl+alt+del. The oom LCA algorithm details 1. New elements add to struct task_struct : struct task_struct *bio_parent struct list_head bio_children; struct list_head bio_sibling; Adds struct task_struct *bio_parent to struct task_struct. Unlike struct task_struct *parent, user programs can not change it by daemon(3). It is describing the facts except when it is a kernel thread. We don't plan to oom kill any kernel threads. 2. If a process is malicious, we'll consider its children malicious too. So we kill the choose process and all its descendants. This way we'll be far faster than the tumor forking. LCA always grows upwards. 3. LCA(Least Common Ancestor Algorithm, I choose the term LCA for it is more widely used than NCA(Nearest Common Ancestor) according to google.) We remember the last killed process' parent, next time we'll kill the remembered last_chosen_parent and the new worst process(the highest badness)'s least common ancestor. NOTE if find_lca() fails, we just kill the worst process and we must _update_ the last_kill_process to a new value. 4. Calculates oom badness bio_children is considered instead of children. Not quite related changes I also include some other obvious cleanups. They are: 1. hides reparent_to_init(), reparent_to_init() should be called only by daemonize() 2. removes obsolete code comments in task_struct 3. removes an obsolete parameter from choose_new_parent() and cleanups 4. in reparent_thread(), ptrace should be type long, not int. 5. cleanups in mm/oom_kill.c Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- arch/i386/mach-voyager/voyager_thread.c |1 include/linux/init_task.h |3 include/linux/sched.h | 10 -- kernel/exit.c | 34 ++- kernel/fork.c |4 mm/oom_kill.c | 141 6 files changed, 129 insertions(+), 64 deletions(-) diff -pruN 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c 2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c --- 2.6.12-rc1-mm3/arch/i386/mach-voyager/voyager_thread.c 2004-08-20 14:39:58.0 +0800 +++ 2.6.12-rc1-mm3-cy/arch/i386/mach-voyager/voyager_thread.c 2005-03-28 10:18:24.0 +0800 @@ -126,7 +126,6 @@ thread(void *unused) kvoyagerd_running = 1; - reparent_to_init(); daemonize(THREAD_NAME); set_timeout = 0; diff -pruN 2.6.12-rc1-mm3/include/linux/init_task.h 2.6.12-rc1-mm3-cy/include/linux/init_task.h --- 2.6.12-rc1-mm3/include/linux/init_task.h2005-03-26 13:21:10.0 +0800 +++ 2.6.12-rc1-mm3-cy/include/linux/init_task.h 2005-03-28 10:18:24.0 +0800 @@ -90,6 +90,9 @@ extern struct group_info init_groups; .parent = tsk, \ .children = LIST_HEAD_INIT(tsk.children), \ .sibling= LIST_HEAD_INIT(tsk.sibling), \ + .bio_parent = tsk, \ + .bio_children = LIST_HEAD_INIT(tsk.bio_children), \ + .bio_sibling
[patch] remove CONFIG_PM_DISK
Hello, Pmdisk was merged in a few months ago. This removes CONFIG_PM_DISK for conditional compilation. Coywolf Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> --- diff -pruN 2.6.11-mm4/arch/i386/defconfig 2.6.11-mm4-cy/arch/i386/defconfig --- 2.6.11-mm4/arch/i386/defconfig 2005-03-17 01:21:16.0 +0800 +++ 2.6.11-mm4-cy/arch/i386/defconfig 2005-03-20 02:24:48.0 +0800 @@ -126,7 +126,6 @@ CONFIG_HAVE_DEC_LOCK=y # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y -# CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support diff -pruN 2.6.11-mm4/arch/i386/mm/init.c 2.6.11-mm4-cy/arch/i386/mm/init.c --- 2.6.11-mm4/arch/i386/mm/init.c 2005-03-17 01:21:17.0 +0800 +++ 2.6.11-mm4-cy/arch/i386/mm/init.c 2005-03-20 02:41:26.0 +0800 @@ -352,7 +352,7 @@ static void __init pagetable_init (void) #endif } -#if defined(CONFIG_PM_DISK) || defined(CONFIG_SOFTWARE_SUSPEND) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * Swap suspend & friends need this for resume because things like the intel-agp * driver might have split up a kernel 4MB mapping. diff -pruN 2.6.11-mm4/mm/page_io.c 2.6.11-mm4-cy/mm/page_io.c --- 2.6.11-mm4/mm/page_io.c 2004-08-20 14:20:15.0 +0800 +++ 2.6.11-mm4-cy/mm/page_io.c 2005-03-20 02:36:54.0 +0800 @@ -127,7 +127,7 @@ out: return ret; } -#if defined(CONFIG_SOFTWARE_SUSPEND) || defined(CONFIG_PM_DISK) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * A scruffy utility function to read or write an arbitrary swap page * and wait on the I/O. The caller must have a ref on the page. - 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] remove CONFIG_PM_DISK
Hello, Pmdisk was merged in a few months ago. This removes CONFIG_PM_DISK for conditional compilation. Coywolf Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] --- diff -pruN 2.6.11-mm4/arch/i386/defconfig 2.6.11-mm4-cy/arch/i386/defconfig --- 2.6.11-mm4/arch/i386/defconfig 2005-03-17 01:21:16.0 +0800 +++ 2.6.11-mm4-cy/arch/i386/defconfig 2005-03-20 02:24:48.0 +0800 @@ -126,7 +126,6 @@ CONFIG_HAVE_DEC_LOCK=y # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y -# CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support diff -pruN 2.6.11-mm4/arch/i386/mm/init.c 2.6.11-mm4-cy/arch/i386/mm/init.c --- 2.6.11-mm4/arch/i386/mm/init.c 2005-03-17 01:21:17.0 +0800 +++ 2.6.11-mm4-cy/arch/i386/mm/init.c 2005-03-20 02:41:26.0 +0800 @@ -352,7 +352,7 @@ static void __init pagetable_init (void) #endif } -#if defined(CONFIG_PM_DISK) || defined(CONFIG_SOFTWARE_SUSPEND) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * Swap suspend friends need this for resume because things like the intel-agp * driver might have split up a kernel 4MB mapping. diff -pruN 2.6.11-mm4/mm/page_io.c 2.6.11-mm4-cy/mm/page_io.c --- 2.6.11-mm4/mm/page_io.c 2004-08-20 14:20:15.0 +0800 +++ 2.6.11-mm4-cy/mm/page_io.c 2005-03-20 02:36:54.0 +0800 @@ -127,7 +127,7 @@ out: return ret; } -#if defined(CONFIG_SOFTWARE_SUSPEND) || defined(CONFIG_PM_DISK) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * A scruffy utility function to read or write an arbitrary swap page * and wait on the I/O. The caller must have a ref on the page. - 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] oom-killer sysrq-f fix
On Thu, Mar 24, 2005 at 05:21:27PM -0800, Andrew Morton wrote:
> Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
> >
> > >>--- 2.6.12-rc1-mm2/mm/oom_kill.c 2005-03-03 17:12:18.0 +0800
> > >>+++ 2.6.12-rc1-mm2-cy/mm/oom_kill.c 2005-03-25 08:07:19.0
> > >>+0800
> > >>@@ -20,6 +20,7 @@
> > >> #include
> > >> #include
> > >> #include
> > >>+#include
> > >>
> > >> /* #define DEBUG */
> > >>
> > >>@@ -283,6 +284,9 @@ retry:
> > >> if (mm)
> > >> mmput(mm);
> > >>
> > >>+ if (in_interrupt())
> > >>+ return;
> > >
> > >
> > > That'll make the whole feature a no-op, won't it?
> >
> > It won't be a no-op. I have tested it. It works well.
> > I pressed sysrq-f, loging bash got killed and I had to re-login.
s/loging bash/login bash/
>
> (looks)
>
> OK. But the patch is still deadlocky because we do task_lock() from
> interrupt context.
Yes, it's deadlocky, but hardly observable in practice. SysRq is just
"taking the risk yourself" to users.
OK, the following patch put moom into workqueue.
Do you agree to put sysrq-e and sysrq-i into workqueue too?
send_sig_all() should do task_lock() too.
Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
diff -pruN 2.6.12-rc1-mm2/drivers/char/sysrq.c
2.6.12-rc1-mm2-cy/drivers/char/sysrq.c
--- 2.6.12-rc1-mm2/drivers/char/sysrq.c 2005-03-25 05:21:39.0 +0800
+++ 2.6.12-rc1-mm2-cy/drivers/char/sysrq.c 2005-03-25 13:28:33.0
+0800
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_KGDB_SYSRQ
@@ -228,12 +229,19 @@ static struct sysrq_key_op sysrq_term_op
.enable_mask= SYSRQ_ENABLE_SIGNAL,
};
-static void sysrq_handle_moom(int key, struct pt_regs *pt_regs,
- struct tty_struct *tty)
+static void moom_callback(void *ignored)
{
out_of_memory(GFP_KERNEL);
// console_loglevel = 8;
}
+
+static DECLARE_WORK(moom_work, moom_callback, NULL);
+
+static void sysrq_handle_moom(int key, struct pt_regs *pt_regs,
+ struct tty_struct *tty)
+{
+ schedule_work(_work);
+}
static struct sysrq_key_op sysrq_moom_op = {
.handler= sysrq_handle_moom,
.help_msg = "Full",
>
> > >
> > > The thing needs to be moved into process context via schedule_work(). I
> > > haven't got around to it yet.
> > >
> >
> > I don't think schedule_work() is a good option here. Since sysrq-f is
> > emergent,
> > we just let oom-killer send SIGKILL in interrupt context and return.
> >
> > We needn't send SIGKILL in a process context. That'll be slow and [events]
> > may got delayed.
>
> There isn't much choice. It should work OK - schedule_task doesn't
> allocate any memory.
>
> keventd could be off allocating some memory somewhere, in which case it
> could take some time to respond, but it isn't worth running another kernel
> thread for sysrq-f.
-
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] oom-killer sysrq-f fix
Andrew Morton wrote: Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: Recent make-sysrq-f-call-oom_kill.patch calls oom-killer in interrupt context, thus results into panic. This patch fixes out_of_memory() to avoid schedule when in interrupt context. Coywolf Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> diff -pruN 2.6.12-rc1-mm2/mm/oom_kill.c 2.6.12-rc1-mm2-cy/mm/oom_kill.c --- 2.6.12-rc1-mm2/mm/oom_kill.c2005-03-03 17:12:18.0 +0800 +++ 2.6.12-rc1-mm2-cy/mm/oom_kill.c 2005-03-25 08:07:19.0 +0800 @@ -20,6 +20,7 @@ #include #include #include +#include /* #define DEBUG */ @@ -283,6 +284,9 @@ retry: if (mm) mmput(mm); + if (in_interrupt()) + return; That'll make the whole feature a no-op, won't it? It won't be a no-op. I have tested it. It works well. I pressed sysrq-f, loging bash got killed and I had to re-login. The thing needs to be moved into process context via schedule_work(). I haven't got around to it yet. I don't think schedule_work() is a good option here. Since sysrq-f is emergent, we just let oom-killer send SIGKILL in interrupt context and return. We needn't send SIGKILL in a process context. That'll be slow and [events] may got delayed. - 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] oom-killer sysrq-f fix
Hello, akpm, I saw you noticed it, http://www.ussg.iu.edu/hypermail/linux/kernel/0412.0/0424.html Jim Nelson, this patch is to your post: 2.6.11-rc2-mm2 - kernel panic with SysRq-f Recent make-sysrq-f-call-oom_kill.patch calls oom-killer in interrupt context, thus results into panic. This patch fixes out_of_memory() to avoid schedule when in interrupt context. Coywolf Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]> diff -pruN 2.6.12-rc1-mm2/mm/oom_kill.c 2.6.12-rc1-mm2-cy/mm/oom_kill.c --- 2.6.12-rc1-mm2/mm/oom_kill.c2005-03-03 17:12:18.0 +0800 +++ 2.6.12-rc1-mm2-cy/mm/oom_kill.c 2005-03-25 08:07:19.0 +0800 @@ -20,6 +20,7 @@ #include #include #include +#include /* #define DEBUG */ @@ -283,6 +284,9 @@ retry: if (mm) mmput(mm); + if (in_interrupt()) + return; + /* * Give "p" a good chance of killing itself before we * retry to allocate memory. - 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] oom-killer sysrq-f fix
Hello, akpm, I saw you noticed it, http://www.ussg.iu.edu/hypermail/linux/kernel/0412.0/0424.html Jim Nelson, this patch is to your post: 2.6.11-rc2-mm2 - kernel panic with SysRq-f Recent make-sysrq-f-call-oom_kill.patch calls oom-killer in interrupt context, thus results into panic. This patch fixes out_of_memory() to avoid schedule when in interrupt context. Coywolf Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED] diff -pruN 2.6.12-rc1-mm2/mm/oom_kill.c 2.6.12-rc1-mm2-cy/mm/oom_kill.c --- 2.6.12-rc1-mm2/mm/oom_kill.c2005-03-03 17:12:18.0 +0800 +++ 2.6.12-rc1-mm2-cy/mm/oom_kill.c 2005-03-25 08:07:19.0 +0800 @@ -20,6 +20,7 @@ #include linux/swap.h #include linux/timex.h #include linux/jiffies.h +#include linux/hardirq.h /* #define DEBUG */ @@ -283,6 +284,9 @@ retry: if (mm) mmput(mm); + if (in_interrupt()) + return; + /* * Give p a good chance of killing itself before we * retry to allocate memory. - 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/
