- 27 Jul, 2005 21 commits
-
-
Jan Kara authored
We must drop references to quota structures before releasing the inode. Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jeff Mahoney authored
reiserfs_new_inode() can call iput() with the xattr lock held. This will cause a deadlock to occur when reiserfs_delete_xattrs() is called to clean up. The following patch releases the lock and reacquires it after the iput. This is safe because interaction with xattrs is complete, and the relock is just to balance out the release in the caller. The locking needs some reworking to be more sane, but that's more intrusive and I was just looking to fix this bug. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jens Axboe authored
AS is doing internal msec<->jiffies conversions twice, so the sysfs tunables which represent time are coming out wrong. The switch from HZ=1000 exposed this. Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Nigel Cunningham authored
Here's a patch to fix a missing refrigerator call in jffs2. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Nigel Cunningham authored
Tvaudio lacks a refrigerator call. This patch fixes that. Signed-off-by: Nigel Cunningham <ncunningham@suspend2.net> Cc: <video4linux-list@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Nigel Cunningham authored
Here are fixes for four try_to_freeze calls that are still (incorrectly) using a parameter after the recent try_to_freeze() changes. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Fixes boot up lockups on some machines where CPU apic ids don't start with 0 Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jeff Dike authored
This fixes an interface which differed from its declaration, and includes the relevant header so that this doesn't happen again. Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dominik Hackl authored
This patch replaces the deprecated MODULE_PARM function by the new module_param function. Signed-off-by: Dominik Hackl <dominik@hackl.dhs.org> Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paolo 'Blaisorblade' Giarrusso authored
This adds the "skas0" parameter to force skas0 operation on SKAS3 host and shows which operating mode has been selected. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Olaf Hering authored
the header file must be build before mk_user_constants. Adding it as a direct dep doesnt work for some reason. arch/um/os-Linux/util/mk_user_constants.c:2:26: error: user-offsets.h: No such file or directory arch/um/os-Linux/util/mk_user_constants.c: In function 'main': arch/um/os-Linux/util/mk_user_constants.c:17: error: '__UM_FRAME_SIZE' undeclared (first use in this function) arch/um/os-Linux/util/mk_user_constants.c:17: error: (Each undeclared identifier is reported only once arch/um/os-Linux/util/mk_user_constants.c:17: error: for each function it appears in.) make[1]: *** [arch/um/os-Linux/util/mk_user_constants] Error 1 Signed-off-by: Olaf Hering <olh@suse.de> Cc: Paolo Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Olaf Hering authored
scripts/Makefile.build:13: /Makefile: No such file or directory scripts/Makefile.build:64: kbuild: Makefile.build is included improperly the define was removed, but its still required to build some targets. Signed-off-by: Olaf Hering <olh@suse.de> Cc: Paolo Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
Without this, and attempt to 'grow' an array will claim to have synced the extra part without actually having done anything. Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Yoichi Yuasa authored
arch/mips/Kconfig is defining CONFIG_FB as bool and drivers/video/Kconfig was changed a while ago to define it as tristate. Remove the MIPS definition. Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alexey Dobriyan authored
One chunk was lost somewhere between my and Andrew's machine. Noticed by Victor Fusco. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Kumar Gala authored
A previous patch to remove support for the OCP device model was way to generious and moved some of the platform device model code, oops. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
include/asm/ptrace.h: In function `user_mode_vm': include/asm/ptrace.h:67: `VM_MASK' undeclared (first use in this function) Cc: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
drivers/char/watchdog/softdog.c:94: too many arguments to function `emergency_restart' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
drivers/char/watchdog/eurotechwdt.c:165: too many arguments to function `emergency_restart' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Chuck Ebbert authored
- make the new user_mode() return 0 or 1 (same as x86_64) - remove conditional jump from user_mode_vm() it's called every timer tick on each CPU on SMP) Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 26 Jul, 2005 19 commits
-
-
Linus Torvalds authored
-
Tom Rini authored
As Marcelo has been spending a great deal of time working on MPC8xx systems of late (thanks!) and has more time than I do now for it, I'm handing this over to him. Signed-off-by: Tom Rini <trini@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Herbert Xu authored
Spotted by, and original patch by, Balazs Scheidler. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steven Rostedt authored
Here's the patch again to fix the code to handle if the values between MAX_USER_RT_PRIO and MAX_RT_PRIO are different. Without this patch, an SMP system will crash if the values are different. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Adrian Bunk authored
The function is not inline. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andreas Steinmetz authored
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by audio users. Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt from sched_setscheduler below: /* * Allow unprivileged RT tasks to decrease priority: */ if (!capable(CAP_SYS_NICE)) { /* can't change policy */ if (policy != p->policy) return -EPERM; After the above unconditional test which causes sched_setscheduler to fail with no regard to the RLIMIT_RTPRIO value the following check is made: /* can't increase priority */ if (policy != SCHED_NORMAL && param->sched_priority > p->rt_priority && param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur) return -EPERM; Thus I do believe that the RLIMIT_RTPRIO value must be taken into account for the policy check, especially as the RLIMIT_RTPRIO limit is of no use without this change. The attached patch fixes this problem. Signed-off-by: Andreas Steinmetz <ast@domdv.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
Remove bogus initialization that was re-done (correctly) later.
-
Ben Dooks authored
Patch from Ben Dooks Split the s3c2440 specific clocks from the arch clock support, to make the code clearer. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Eric W. Biederman authored
Now that all of the code paths that call acpi_power_off have been modified to call either call kernel_power_off (which calls apci_sleep_prepare by way of acpi_shutdown) or to call acpi_sleep_prepare directly it is redundant to call acpi_sleep_prepare from acpi_power_off. So simplify the code and simply don't call acpi_sleep_prepare. In addition there is a little error handling done so if we can't register the acpi class we don't hook pm_power_off. I think I have done the right thing with the CONFIG_PM define but I'm not certain. Can this code even be compiled if CONFIG_PM is false? Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
machine_power_off on i386 and x86_64 now switch to the boot cpu out of paranoia and because the MP Specification indicates it is a good idea on reboot, so for those architectures it is a noop. I can't see anything in the acpi spec that requires you to be on the boot cpu to power off the system, so this should not be an issue for ia64. In addition ia64 has the altix a massive multi-node system where switching to the boot cpu sounds insane as we may hot removed the boot cpu. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
i386 machine_power_off was disabling the local apic and all of it's users wanted to be on the boot cpu. So call machine_shutdown which places us on the boot cpu and disables the apics. This keeps us in sync and reduces the number of cases we need to worry about in the power management code. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
machine_power_off now always switches to the boot cpu so there is no reason for APM to also do that. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
Call machine_shutdown() to move to the boot cpu and disable apics. Both acpi_power_off and apm_power_off want to move to the boot cpu. and we are already disabling the local apics so calling machine_shutdown simply reuses code. ia64 doesn't have a special path in power_off for efi so there is no reason i386 should. If we really need to call the efi power off path the efi driver can set pm_power_off like everyone else. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
This appears to be a typo I introduced when cleaning this code up earlier. Ooops. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
The call appears to come from process context so kernel_power_off should be safe. And acpi_power_off won't necessarily work if you just call machine_power_off. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
The suspend to disk code was a poor copy of the code in sys_reboot now that we have kernel_power_off, kernel_restart and kernel_halt use them instead of poorly duplicating them inline. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Eric W. Biederman authored
The 68328serial.c driver has a weird local reimplementation of magic sysrq. The code is architecture specific enough that calling machine_restart() is probably ok. But there is no reason not to call emergency_restart() so do so. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-