- 11 Apr, 2006 40 commits
-
-
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:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
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:
Vivek Goyal <vgoyal@in.ibm.com> Cc: <stable@kernel.org> 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:
-
Christoph Hellwig authored
Signed-off-by:
-
Herbert Poetzl authored
The mnt_flags are propagated into do_loopback(), so that they can be stored with the vfsmount Signed-off-by:
Herbert Poetzl <herbert@13thfloor.at> Acked-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Ben Dooks authored
Lay out the structure definitions in include/linux/leds.h to be aligned as much as possible. Also minor updates to the comments to make them more concise. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Acked-by:
Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Ben Dooks authored
Reorganise the drivers/leds Kconfig file to have the LED trigger enable with the triggers themselves. Also add comments to divide up the sections into the drivers and triggers Signed-off-by:
-
Ben Dooks authored
The IDE Disk LED trigger has the same name as the timer trigger. Signed-off-by:
-
Ben Dooks authored
GPIO LED support for Samsung S3C24XX SoC series processors. Signed-off-by:
-
Adrian Bunk authored
Implement the scheduled unexport of panic_timeout. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Andrew Morton authored
We need the boot CPU's tvec_bases[] entry to be initialised super-early in boot, for early_serial_setup(). That runs within setup_arch(), before even per-cpu areas are initialised. The patch changes tvec_bases to use compile-time initialisation, and adds a separate array `tvec_base_done' to keep track of which CPU has had its tvec_bases[] entry initialised (because we can no longer use the zeroness of that tvec_bases[] entry to determine whether it has been initialised). Thanks to Eugene Surovegin <ebs@ebshome.net> for diagnosing this. Cc: Eugene Surovegin <ebs@ebshome.net> Cc: Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Andrew Morton authored
Ulrich suggested that the `flags' arg to sync_file_range() become unsigned. Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Kyle McMartin authored
Some string functions were safely overrideable in lib/string.c, but their corresponding declarations in linux/string.h were not. Correct this, and make strcspn overrideable. Odds of someone wanting to do optimized assembly of these are small, but for the sake of cleanliness, might as well bring them into line with the rest of the file. Signed-off-by:
Kyle McMartin <kyle@parisc-linux.org> Signed-off-by:
-
Kyle McMartin authored
While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by:
-
Yasunori Goto authored
Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for each arch. Its definition is sometimes configurable. Indeed, ia64 defines 5 NODES_SHIFT values in the current git tree. But it looks a bit messy. SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has been changeable by config. Suitable node's number may be changed in the future even if it is other architecture. So, I wrote configurable node's number. This patch set defines just default value for each arch which needs multi nodes except ia64. But, it is easy to change to configurable if necessary. On ia64 the number of nodes can be already configured in generic ia64 and SN2 config. But, NODES_SHIFT is defined for DIG64 and HP'S machine too. So, I changed it so that all platforms can be configured via CONFIG_NODES_SHIFT. It would be simpler. See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jack Steiner <steiner@sgi.com> Signed-off-by:
-
Frank Gevaerts authored
This adds support for my Thinkpad R52, which for some reason is not matched by the "ThinkPad R52" line. Signed-off-by:
Frank Gevaerts <frank@gevaerts.be> Cc: Robert Love <rml@novell.com> Cc: Dmitry Torokhov <dtor_core@ameritech.net> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Dave Jones authored
include/asm/atomic.h:94: warning: implicit declaration of function 'unlikely' include/asm/atomic.h:97: warning: implicit declaration of function 'likely' Signed-off-by:
-
Adrian Bunk authored
-finline-limit might have been required for older compilers, but nowadays it does no longer make sense. Signed-off-by:
-
Peter Oberparleiter authored
Cleanup of minor bugs found by a source code checker. Signed-off-by:
Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
