- 03 Apr, 2009 40 commits
-
-
Jack Steiner authored
Add definitions for x86_64 GRU MMRs. Signed-off-by:
Jack Steiner <steiner@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jack Steiner authored
Eliminate compile errors on 32-bit X86 caused by UV. Signed-off-by:
-
Aravind Srinivasan authored
Fix possible loss/corruption of produced subbufs in relay_subbufs_consumed(). When buf->subbufs_produced wraps around after UINT_MAX and buf->subbufs_consumed is still < UINT_MAX, the condition if (buf->subbufs_consumed > buf->subbufs_produced) will be true even for certain valid values of subbufs_consumed. This may lead to loss or corruption of produced subbufs. Signed-off-by:
Aravind Srinivasan <raa.aars@gmail.com> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Tom Zanussi <zanussi@us.ibm.com> Signed-off-by:
-
Dmitri Vorobiev authored
The vmcoreinfo_data[] array is not used outside of kernel/kexec.c, and can therefore become static. This patch adds the relevant keyword to the definition of the array. Noticed by sparse. Signed-off-by:
Dmitri Vorobiev <dmitri.vorobiev@movial.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Neil Horman authored
It would be nice to be able to extract the dmesg log from a vmcore file without needing to keep the debug symbols for the running kernel handy all the time. We have a facility to do this in /proc/vmcore. This patch adds the log_buf and log_end symbols to the vmcoreinfo area so that tools (like makedumpfile) can easily extract the dmesg logs from a vmcore image. [akpm@linux-foundation.org: several fixes and cleanups] [akpm@linux-foundation.org: fix unused log_buf_kexec_setup()] [akpm@linux-foundation.org: build fix] Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Cc: Simon Horman <horms@verge.net.au> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Daniel Mack authored
This fixes a number of coding style issues I stubled over. Acked-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
Daniel Mack <daniel@caiaq.de> Signed-off-by:
-
Philippe De Muyter authored
netmos serial/parallel adapters come in different flavour differing only by the number of parallel and serial ports, which are encoded in the subdevice ID. Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S, and works only by side-effect for the first parallel port of a 2P2S, as this first parallel port is found by reading the second addr entry of (struct parport_pc_pci) cards[netmos_9855], which is not initialized, and hence has value 0, which happens to be the BAR of the first parallel port. netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used for a 9845 1P4S must also be fixed for the parallel port support when there are 4 serial ports because this entry currently gives 2 as BAR index for the parallel port. Actually, in this case, BAR 2 is the 3rd serial port while the parallel port is at BAR 4. I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support, - by creating a netmos_9855_2p entry and using it for 9855 boards with 2 parallel ports : 9855 2P2S and 9855 2P0S boards, - and by allowing netmos_parallel_init to change not only the number of parallel ports (0 or 1), but making it also change the BAR index of the parallel port when the serial ports are before the parallel port. PS: the netmos_9855_2p entry in (struct pciserial_board) pci_parport_serial_boards[] is needed because netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4 in the description of the serial ports in function of the number of parallel ports on the card. Tested with 9845 1P4S, 9855 1P4S and 9855 2P2S boards. Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Tested-by:
Christian Pellegrin <chripell@fsfe.org> Signed-off-by:
-
Harry Ciao authored
Introduce Kconfig and Makefile options for AMD8111 EDAC driver. Signed-off-by:
Harry Ciao <qingtao.cao@windriver.com> Cc: Doug Thompson <norsk5@yahoo.com> Signed-off-by:
-
Harry Ciao authored
Introduce Kconfig and Makefile options for AMD8131 EDAC driver. Signed-off-by:
-
Harry Ciao authored
Introduce AMD8131 EDAC driver source file, which makes use of error detections on the PCI-X Bridge Controllers on the AMD8131 HyperTransport PCI-X Tunnel. Signed-off-by:
-
Harry Ciao authored
Introduce AMD8131 EDAC driver header file, which adds register and bits definitions for the PCI-X Bridge Controller on the AMD8131 HyperTransport I/O Hub. Signed-off-by:
-
Harry Ciao authored
Add the PCI Device ID of the PCI Bridge Controller on AMD8111 chip. Signed-off-by:
-
Harry Ciao authored
Add edac_pci_alloc_index(), because for MAPLE platform there may exist several EDAC driver modules that could make use of edac_pci_ctl_info structure at the same time. The index allocation for these structures should be taken care of by EDAC core. Signed-off-by:
-
Harry Ciao authored
Introduce AMD8111 EDAC driver source file, which makes use of error detections on the LPC Bridge Controller and PCI Bridge Controller on the AMD8111 HyperTransport I/O Hub. Signed-off-by:
-
Harry Ciao authored
Introduce AMD8111 EDAC driver header file, which adds register and bits definitions for the LPC Bridge Controller and PCI Bridge Controller on the AMD8111 HyperTransport I/O Hub. Signed-off-by:
-
Grant Erickson authored
This adds support for an EDAC memory controller adaptation driver for the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC 405EX[r]. At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) "ibm,sdram-4xx" - IBM DDR1 (440GP, 440GX, 440EP and 440GR) "ibm,sdram-4xx-ddr" - Denali DDR1/DDR2 (440EPX and 440GRX) "denali,sdram-4xx-ddr2" [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Grant Erickson <gerickson@nuovations.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Doug Thompson authored
After 3 years, this is a patch to remove the EXPERIMENTAL tag on EDAC. We now have many module drivers submitters in EDAC and believe EDAC is no longer EXPERIMENTAL Signed-off-by: Doug Thompson <dougthompson@xmission.com Signed-off-by:
-
Hitoshi Mitake authored
A patch for making a debugging information more verbose for use in development debugging. By enabling the new option "More verbose debugging", information about source file and line number will be added to debugging message. This is sample output, EDAC MC0: Giving out device to 'e7xxx_edac' 'E7205': DEV 0000:00:00.0 EDAC DEBUG: in drivers/edac/edac_pci.c, line at 48: edac_pci_alloc_ctl_info() EDAC DEBUG: in drivers/edac/edac_pci.c, line at 334: edac_pci_add_device() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Signed-off-by:Hitoshi Mitake <h.mitake@gmail.com> Signed-off-by:
-
Pavel Machek authored
Trivial cleanups for nbd: only the return -EIO one really changes code, and I've verified all the callers (plus 0 == success, 1 == error convention is really ugly). Signed-off-by:
Pavel Machek <pavel@suse.cz> Acked-by:
Paul Clements <paul.clements@steeleye.com> Signed-off-by:
-
Pavel Machek authored
The code was written to rely on big kernel lock to protect it from races. It mostly works when interface is not abused. So this uses tx_lock to protect data structures from concurrent use between ioctl and worker threads. Next step will be moving from ioctl to unlocked_ioctl. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: add missing return] Signed-off-by:
-
Oleg Nesterov authored
We are wasting 2 words in signal_struct without any reason to implement task_pgrp_nr() and task_session_nr(). task_session_nr() has no callers since 2e2ba22e, we can remove it. task_pgrp_nr() is still (I believe wrongly) used in fs/autofsX and fs/coda. This patch reimplements task_pgrp_nr() via task_pgrp_nr_ns(), and kills __pgrp/__session and the related helpers. The change in drivers/char/tty_io.c is cosmetic, but hopefully makes sense anyway. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by: Alan Cox <number6@the-village.bc.nu> [tty parts] Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@openvz.org> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: Roland McGrath <roland@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
Inho, the safety rules for vnr/nr_ns helpers are horrible and buggy. task_pid_nr_ns(task) needs rcu/tasklist depending on task == current. As for "special" pids, vnr/nr_ns helpers always need rcu. However, if task != current, they are unsafe even under rcu lock, we can't trust task->group_leader without the special checks. And almost every helper has a callsite which needs a fix. Also, it is a bit annoying that the implementations of, say, task_pgrp_vnr() and task_pgrp_nr_ns() are not "symmetrical". This patch introduces the new helper, __task_pid_nr_ns(), which is always safe to use, and turns all other helpers into the trivial wrappers. After this I'll send another patch which converts task_tgid_xxx() as well, they're are a bit special. Signed-off-by:
-
Oleg Nesterov authored
sys_wait4() does get_pid(task_pgrp(current)), this is not safe. We can add rcu lock/unlock around, but we already have get_task_pid() which can be improved to handle the special pids in more reliable manner. Signed-off-by:
-
Oleg Nesterov authored
Even if task == current, it is not safe to dereference the result of task_pgrp/task_session. We can race with another thread which changes the special pid via setpgid/setsid. Document this. The next 2 patches give an example of the unsafe usage, we have more bad users. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Matthew Wilcox authored
Arne de Bruijn points out that commit 76fdbb25 ("coredump masking: bound suid_dumpable sysctl") mistakenly limits lease-break-time instead of suid_dumpable. Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Reported-by:
Arne de Bruijn <kernelbt@arbruijn.dds.nl> Cc: Kawai, Hidehiro <hidehiro.kawai.ez@hitachi.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: <stable@kernel.org> Signed-off-by:
-
Yasunori Goto authored
hpet_calibrate() has a possibility of miss-calibration due to SMI. If SMI interrupts in the while loop of calibration, then return value will be big. This change calibrates until stabilizing by the return value with a small value. [akpm@linux-foundation.org: trivial style tweaks] Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Acked-by:
Vojtech Pavlik <vojtech@suse.cz> Cc: Robert Picco <Robert.Picco@hp.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Acked-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul Fulghum authored
Add support for x8 asynchronous sample rate and ability to specify base clock frequency. Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by:
-
Mike Frysinger authored
Signed-off-by:
Mike Frysinger <vapier.adi@gmail.com> Signed-off-by:
Bryan Wu <cooloney@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: Greg Ungerer <gerg@snapgear.com> Signed-off-by:
-
Serge E. Hallyn authored
As pointed out by Cedric Le Goater (in response to Alexey's original comment wrt mqns), ipc_sysctl.c and utsname_sysctl.c are using CONFIG_PROC_FS, not CONFIG_PROC_SYSCTL, to determine whether to define the proc_handlers. Change that. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Acked-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Tony Battersby authored
shm_get_stat() assumes idr_find(&shm_ids(ns).ipcs_idr) returns "struct shmid_kernel *"; all other callers assume that it returns "struct kern_ipc_perm *". This works because "struct kern_ipc_perm" is currently the first member of "struct shmid_kernel", but it would be better to use container_of() to prevent future breakage. Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Cc: Jiri Olsa <olsajiri@gmail.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Lai Jiangshan authored
cpuhotplug_mutex_lock() is not used, remove it. Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Rusty Russell <rusty@rustcorp.com.au> Acked-by:
Gautham R Shenoy <ego@in.ibm.com> Signed-off-by:
-
Lai Jiangshan authored
1) lockdep will complain when run_workqueue() performs recursion. 2) The recursive implementation of run_workqueue() means that flush_workqueue() and its documentation are inconsistent. This may hide deadlocks and other bugs. 3) The recursion in run_workqueue() will poison cwq->current_work, but flush_work() and __cancel_work_timer(), etcetera need a reliable cwq->current_work. Signed-off-by:
-
Oleg Nesterov authored
This bug is ancient too. ptrace_untrace() must not resume the task if the group stop in progress, we should set TASK_STOPPED instead. Unfortunately, we still have problems here: - if the process/thread was traced, SIGNAL_STOP_STOPPED does not necessary means this thread group is stopped. - ptrace breaks the bookkeeping of ->group_stop_count. Signed-off-by:
-
Oleg Nesterov authored
Another ancient bug. Consider this trivial test-case, int main(void) { int pid = fork(); if (pid) { ptrace(PTRACE_ATTACH, pid, NULL, NULL); wait(NULL); ptrace(PTRACE_DETACH, pid, NULL, NULL); } else { pause(); printf("WE HAVE A KERNEL BUG!!!\n"); } return 0; } the child must not "escape" for sys_pause(), but it can and this was seen in practice. This is because ptrace_detach does: if (!child->exit_state) wake_up_process(child); this wakeup can happen after this child has already restarted sys_pause(), because it gets another wakeup from ptrace_untrace(). With or without this patch, perhaps sys_pause() needs a fix. But this wakeup also breaks the SIGNAL_STOP_STOPPED logic in ptrace_untrace(). Remove this wakeup. The caller saw this task in TASK_TRACED state, and unless it was SIGKILL'ed in between __ptrace_unlink()->ptrace_untrace() should handle this case correctly. If it was SIGKILL'ed, we don't need to wakup the dying tracee too. Signed-off-by:Roland McGrath <roland@redhat.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
Now that task_detached() is exported, change tracehook_notify_death() to use this helper, nobody else checks ->exit_signal == -1 by hand. Signed-off-by:
-
Oleg Nesterov authored
By discussion with Roland. - Use ->sibling instead of ->ptrace_entry to chain the need to be release_task'd childs. Nobody else can use ->sibling, this task is EXIT_DEAD and nobody can find it on its own list. - rename ptrace_dead to dead_childs. - Now that we don't have the "parallel" untrace code, change back reparent_thread() to return void, pass dead_childs as an argument. Actually, I don't understand why do we notify /sbin/init when we reparent a zombie, probably it is better to reap it unconditionally. [akpm@linux-foundation.org: s/childs/children/] Signed-off-by:
-
Oleg Nesterov authored
By discussion with Roland. - Rename ptrace_exit() to exit_ptrace(), and change it to do all the necessary work with ->ptraced list by its own. - Move this code from exit.c to ptrace.c - Update the comment in ptrace_detach() to explain the rechecking of the child->ptrace. Signed-off-by:
-
Oleg Nesterov authored
If /sbin/init ignores SIGCHLD and we re-parent a zombie, it is leaked. reparent_thread() does do_notify_parent() which sets ->exit_signal = -1 in this case. This means that nobody except us can reap it, the detached task is not visible to do_wait(). Change reparent_thread() to return a boolean (like __pthread_detach) to indicate that the thread is dead and must be released. Also change forget_original_parent() to add the child to ptrace_dead list in this case. The naming becomes insane, the next patch does the cleanup. Signed-off-by:
-
Oleg Nesterov authored
reparent_thread() uses ptrace_reparented() to check whether this thread is ptraced, in that case we should not notify the new parent. But ptrace_reparented() is not exactly correct when the reparented thread is traced by /sbin/init, because forget_original_parent() has already changed ->real_parent. Currently, the only problem is the false notification. But with the next patch the kernel crash in this (yes, pathological) case. Signed-off-by:
-
