- 11 Apr, 2006 40 commits
-
-
Alessandro Zummo authored
Move the "24hr: yes" proc output from drivers to rtc proc code. This is required because the time value in the proc output is always in 24hr mode regardless of the driver. Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Alessandro Zummo authored
- fix whitespace - remove some debugging in excess Signed-off-by:
-
Alessandro Zummo authored
Fix sysfs show() return code Signed-off-by:
-
Alessandro Zummo authored
- removed a duplicate error message - bumped driver version - removed some debugging messages in excess - refined the formatting - adjusted copyright notice Signed-off-by:
-
Kumar Gala authored
* Always enable the oscillator when we set the time * If the oscillator is disable when we probe the RTC report back a warning to the user * Added sysfs attribute to represent the state of the oscillator Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
-
Ananiev, Leonid I authored
Missed unlock_super()call is added in error condition code path. Signed-off-by:
Leonid Ananiev <leonid.i.ananiev@intel.com> Cc: <stable@kernel.org> Signed-off-by:
-
Eric Sesterhenn authored
This fixes coverity bug id #473. After the for loop i==16 if we didn't find a cdrom. So we should check for i==16 first before checking the array element. Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Cc: Jens Axboe <axboe@suse.de> Signed-off-by:
-
Eric Sesterhenn authored
This fixes coverity bug id #469. The out of range check didnt work as intended, as seen by the printk(), which states that boardno has to be 1 <= boardno <= MAX_BOARD. Signed-off-by:
-
Coywolf Qi Hunt authored
Signed-off-by:
Coywolf Qi Hunt <qiyong@fc-cn.com> Signed-off-by:
-
Andrew Morton authored
We must disable local IRQs while holding KM_IRQ0 or KM_IRQ1. Otherwise, an IRQ handler could use those kmap slots while this code is using them, resulting in memory corruption. Thanks to Nick Orlov <bugfixer@list.ru> for reporting. Cc: <linuxraid@amcc.com> Cc: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Andrew Morton authored
Use ENODEV when the hdaps hardware isn't there, not ENXIO. Cc: Jean Delvare <khali@linux-fr.org> Cc: Robert Love <rml@novell.com> Signed-off-by:
-
Corey Minyard authored
The event handler mechanism in the IPMI driver had a limit on the number of received events, but the counts were not being updated. Update the counts to impose a limit. This is not a critical fix, as this function (the sending of the events) has to be turned on by the user, anyway. This avoids problems if they forget to turn it back off. Signed-off-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Arnd Bergmann authored
The spufs file system creates files in a directory before instantiating the directory itself, which causes a NULL pointer access in inotify_d_instantiate since c32ccd87. I'd like to keep this behavior since it means that the user will not have access to files in the directory before I know that I succeed in creating everything in it. This patch adds a simple check for the inode to keep that working. Signed-off-by:
Arnd Bergmann <arnd.bergmann@de.ibm.com> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Vivek Goyal authored
Everybody seems to be using /proc/vmcore as a method to access the kernel crash dump. Hence probably it makes sense to enable CONFIG_PROC_VMCORE by default if CONFIG_CRASH_DUMP is selected. This makes kdump configuration further easier for a user. Signed-off-by:
Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
An UML user reported (against 2.6.13.3/UML) he got kernel Oopses when trying to rmmod (on a kernel with module unloading enabled) a module compiled with module unloading disabled. As crashing is a very correct thing to do in that case, a solution is altering the vermagic string to include this too. Possibly, however, the code should not crash in this case, even if the module didn't support unloading - it should simply abort the module removal. In this case, fixing that bug would be a better solution. I've not investigated though. (akpm: a bit marginal - root screwed up and shot himself in the foot). Cc: Hayim Shaul <hayim@post.tau.ac.il> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Martin Michlmayr authored
Remove a duplicated entry from parport_serial_pci_tbl. Signed-off-by:
Martin Michlmayr <tbm@cyrius.com> Signed-off-by:
-
Randy Dunlap authored
Eric is the kexec maintainer. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
David Howells authored
Remove an unnecessary memory barrier (implicit in rcu_dereference()) from install_session_keyring(). install_session_keyring() is also rearranged a little to make it slightly more efficient. As install_*_keyring() may schedule (in synchronize_rcu() or keyring_alloc()), they may not be entered with interrupts disabled - and so there's no point saving the interrupt disablement state over the critical section. exec_keys() will also be invoked with interrupts enabled, and so that doesn't need to save the interrupt state either. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Geert Uytterhoeven authored
Update contact info for Geert Uytterhoeven Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
David Howells authored
In the memory barrier document, improve the example of the data dependency barrier situation by: (1) showing the initial values of the variables involved; and (2) repeating the instruction sequence description, this time with the data dependency barrier actually shown to make it clear what the revised sequence actually is. Signed-off-by: -
David Howells authored
Fix the memory barrier documentation to attempt to describe atomic ops correctly. atomic_t ops that return a value _do_ imply smp_mb() either side, and so don't actually require smp_mb__*_atomic_*() special barriers. Also explains why special barriers exist in addition to normal barriers. Further fix the memory barrier documents to portray bitwise operation memory barrier effects correctly following Nick Piggin's comments. It makes the point that any atomic op that both modifies some state in memory and returns information on that state implies memory barriers on both sides. Signed-off-by:
-
Randy Dunlap authored
Fix mtrr-add.c and mtrr-show.c in Doc/mtrr.txt to build cleanly. Signed-off-by:
-
Randy Dunlap authored
Fix C source file in Doc/laptop-mode.txt to compile. Signed-off-by:
-
Tobias Klauser authored
These are the last conversions of pci_set_dma_mask(), pci_set_consistent_dma_mask() and pci_dma_supported() to use DMA_xBIT_MASK constants from linux/dma-mapping.h Signed-off-by:
Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by:
-
Mark Bellon authored
The MPBL0010 Telco clock driver (drivers/char/tlclk.c) uses 0222 (anyone can write) permissions on its writable sysfs entries. Alter the permissions to 0220 (owner and group can write). The use case for this driver is to configure the fail over behavior of the clock hardware. That should be done by the more privileged users. Signed-off-by:
Mark Bellon <mbellon@mvista.com> Acked-by:
"Gross, Mark" <mark.gross@intel.com> Cc: <stable@kernel.org> Signed-off-by:
-
Paul Fulghum authored
Remove dead code from tty_io.c release_dev() Signed-off-by:
-
Paul Fulghum authored
Remove duplicate call to idr_remove() in ptmx_open. Error during open can result in call to release_dev() followed by call to idr_remove(). release_dev already calls idr_remove so the second call can cause a stack dump in idr_remove()->sub_remove() flagging an attempt to release an already released entry. I reproduces this on a machine with a misconfigured X server (attempting to restart multiple times rapidly) getting the same error as the 1st link below. This also seems to be related to: http://marc.theaimsgroup.com/?l=selinux&m=110536513426735&w=2 http://marc.theaimsgroup.com/?l=selinux&m=110596994916785&w=2 The stack dump can occur on close (as well as open) as shown in the 1st instance above, possible from something like: process A - open (index=0), open fail to out1, release_dev calls idr_remove (index 0), down(sem) sleeps process B - open (index=0), open OK (idr allocated) process A - wake and call idr_remove on index 0 ... process B - close, release_dev, stack dump on idr_remove (index=0) because entry already removed Signed-off-by:
-
Joern Engel authored
Remove the blkmtd driver. - An alternative exists (block2mtd) that hasn't had bug report for > 1 year. - Most embedded people tend to use ancient kernels with custom patches from mtd cvs and elsewhere, so the 1 year warning period neither helps nor hurts them too much. - It's in the way of klibc. The problems caused by pulling blkmtd support are fairly low, while the problems caused by delaying klibc can be fairly substantial. At best, this would be a severe burden on hpa's time. Signed-off-by:
Joern Engel <joern@wohnheim.fh-wedel.de> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Roland McGrath authored
The only record we have of the real-time age of a process, regardless of execs it's done, is start_time. When a non-leader thread exec, the original start_time of the process is lost. Things looking at the real-time age of the process are fooled, for example the process accounting record when the process finally dies. This change makes the oldest start_time stick around with the process after a non-leader exec. This way the association between PID and start_time is kept constant, which seems correct to me. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Andrew Morton authored
__NR_sys_kexec_load should be __NR_kexec_load. Mainly affects users of the _syscallN() macros, and glibc is already checking for __NR_kexec_load. Cc: Ulrich Drepper <drepper@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Mikael Starvik <starvik@axis.com> Cc: David Howells <dhowells@redhat.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp> Signed-off-by:
-
Joe Korty authored
Add a cpu_relax() to the hand-coded spinwait in hrtimer_cancel(). Signed-off-by:
Joe Korty <joe.korty@ccur.com> Acked-by:
-
Davide Libenzi authored
As reported by Michael Kerrisk, POLLRDHUP handling was not consistent between epoll and poll/select, since in epoll it was unmaskeable. This patch brings uniformity in POLLRDHUP handling. Signed-off-by:
Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk-manpages@gmx.net> Signed-off-by:
-
Robert Love authored
Add support for forthcoming Lenovo-branded machines to the HDAPS driver. Signed-off-by:
Robert Love <rml@novell.com> Cc: Jean Delvare <khali@linux-fr.org> Cc: Dmitry Torokhov <dtor_core@ameritech.net> Signed-off-by:
-
Vivek Goyal authored
A couple of /proc/vmcore data structures overflow with 32bit systems having memory more than 4G. This patch fixes those. Signed-off-by:
Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Signed-off-by:
-
Jan-Benedict Glaw authored
lib/string.c: In function 'memcpy': lib/string.c:470: warning: initialization discards qualifiers from pointer = target type Signed-off-by:
Jan-Benedict Glaw <jbglaw@lug-owl.de> Signed-off-by:
-
Mitchell Blank Jr authored
If SELECT_STACK_ALLOC is not a multiple of sizeof(long) then stack_fds[] would be shorter than SELECT_STACK_ALLOC bytes and could overflow later in the function. Fixed by simply rearranging the test later to work on sizeof(stack_fds) Currently SELECT_STACK_ALLOC is 256 so this doesn't happen, but it's nasty to have things like this hidden in the code. What if later someone decides to change SELECT_STACK_ALLOC to 300? Signed-off-by:
Mitchell Blank Jr <mitch@sfgoth.com> Signed-off-by:
-
Keith Owens authored
Before commit 47e65328, next_thread() took a const task_t. Reinstate the const qualifier, getting the next thread never changes the current thread. Signed-off-by:
Keith Owens <kaos@sgi.com> Signed-off-by:
-
Dave Jones authored
Doubletalk printk's an extraneous \n Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Eric Van Hensbergen authored
Handle a failing sget() in v9fs_get_sb(). Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Eric Van Hensbergen <ericvh@gmail.com> Signed-off-by:
-
Andrew Morton authored
We changed the wrong symbol. It's tty_insert_flip_string_flags() which is called from the previously-non-GPL'ed now-inlined tty_insert_flip_char(). Fix that up, and uninline tty_schedule_flip() while we're there. Cc: Tobias Powalowski <t.powa@gmx.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
