- 24 Apr, 2007 12 commits
-
-
Christoph Lameter authored
NR_FILE_PAGES must be accounted for depending on the zone that the page belongs to. If we replace the page in the radix tree then we may have to shift the count to another zone. Suggested-by:
Ethan Solomita <solo@google.com> Eventually-typed-in-by:
Christoph Lameter <clameter@sgi.com> Cc: Martin Bligh <mbligh@mbligh.org> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Miguel Ojeda authored
Signed-off-by:
Miguel Ojeda Sandonis <maxextreme@gmail.com> Cc: "Antonino A. Daplas" <adaplas@gmail.com> Signed-off-by:
-
Michael Buesch authored
Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Alexey Dobriyan authored
pcd_lock and pf_spin_lock are passed to blk_init_queue() which, seeing them as valid lock pointer, sets it as ->queue_lock. The problem is that pcd_lock and pf_spin_lock aren't initialized anywhere. Signed-off-by:
Alexey Dobriyan <adobriyan@sw.ru> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
David Brownell authored
Update various mailing list addresses to use "lists.linux-foundation.org" instead of "lists.osdl.org", to help phase out the old addresses. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Balbir Singh authored
We broke the the alignment of members of taskstats to the 8 byte boundary with the CSA patches. In the current kernel, the taskstats structure is not suitable for use by 32 bit applications in a 64 bit kernel. On x86_64 Offsets of taskstats' members (64 bit kernel, 64 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 116, # ac_uid 120, # ac_gid 124, # ac_pid 128, # ac_ppid 132, # ac_btime 136, # ac_etime 144, # ac_utime 152, # ac_stime 160, # ac_minflt 168, # ac_majflt 176, # coremem 184, # virtmem 192, # hiwater_rss 200, # hiwater_vm 208, # read_char 216, # write_char 224, # read_syscalls 232, # write_syscalls 240, # read_bytes 248, # write_bytes 256, # cancelled_write_bytes ); Offsets of taskstats' members (64 bit kernel, 32 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 12, # cpu_count 20, # cpu_delay_total 28, # blkio_count 36, # blkio_delay_total 44, # swapin_count 52, # swapin_delay_total 60, # cpu_run_real_total 68, # cpu_run_virtual_total 76, # ac_comm 108, # ac_sched 109, # ac_pad 112, # ac_uid 116, # ac_gid 120, # ac_pid 124, # ac_ppid 128, # ac_btime 132, # ac_etime 140, # ac_utime 148, # ac_stime 156, # ac_minflt 164, # ac_majflt 172, # coremem 180, # virtmem 188, # hiwater_rss 196, # hiwater_vm 204, # read_char 212, # write_char 220, # read_syscalls 228, # write_syscalls 236, # read_bytes 244, # write_bytes 252, # cancelled_write_bytes ); This is one way to solve the problem without re-arranging structure members is to pack the structure. The patch adds an __attribute__((aligned(8))) to the taskstats structure members so that 32 bit applications using taskstats can work with a 64 bit kernel. Using __attribute__((packed)) would break the 64 bit alignment of members. The fix was tested on x86_64. After the fix, we got Offsets of taskstats' members (64 bit kernel, 64 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 120, # ac_uid 124, # ac_gid 128, # ac_pid 132, # ac_ppid 136, # ac_btime 144, # ac_etime 152, # ac_utime 160, # ac_stime 168, # ac_minflt 176, # ac_majflt 184, # coremem 192, # virtmem 200, # hiwater_rss 208, # hiwater_vm 216, # read_char 224, # write_char 232, # read_syscalls 240, # write_syscalls 248, # read_bytes 256, # write_bytes 264, # cancelled_write_bytes ); Offsets of taskstats' members (64 bit kernel, 32 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 120, # ac_uid 124, # ac_gid 128, # ac_pid 132, # ac_ppid 136, # ac_btime 144, # ac_etime 152, # ac_utime 160, # ac_stime 168, # ac_minflt 176, # ac_majflt 184, # coremem 192, # virtmem 200, # hiwater_rss 208, # hiwater_vm 216, # read_char 224, # write_char 232, # read_syscalls 240, # write_syscalls 248, # read_bytes 256, # write_bytes 264, # cancelled_write_bytes ); Signed-off-by:Balbir Singh <balbir@linux.vnet.ibm.com> Cc: Jay Lan <jlan@engr.sgi.com> Cc: Shailabh Nagar <nagar@watson.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jiri Slaby authored
There was schedule() missing in the TIOCMIWAIT ioctl. Solve it by moving the code to the wait_event_interruptible. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Cc: Jan Yenya Kasprzak <kas@fi.muni.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Jiri Slaby authored
There was schedule() missing in the TIOCMIWAIT ioctl. Solve it by moving the code to the wait_event_interruptible. Cc: Jan "Yenya" Kasprzak <kas@fi.muni.cz> Signed-off-by:
-
Jan Yenya Kasprzak authored
Signed-off-by:
Jan "Yenya" Kasprzak <kas@fi.muni.cz> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Hugh Dickins authored
I only have CONFIG_NUMA=y for build testing: surprised when trying a memhog to see lots of other processes killed with "No available memory (MPOL_BIND)". memhog is killed correctly once we initialize nodemask in constrained_alloc(). Signed-off-by:
Hugh Dickins <hugh@veritas.com> Acked-by:
William Irwin <bill.irwin@oracle.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@kernel.org> Signed-off-by:
-
Taku Izumi authored
I encountered the following kernel panic. The cause of this problem was NULL pointer access in check_modem_status() in 8250.c. I confirmed this problem is fixed by the attached patch, but I don't know this is the correct fix. sadc[4378]: NaT consumption 2216203124768 [1] Modules linked in: binfmt_misc dm_mirror dm_mod thermal processor fan container button sg e100 eepro100 mii ehci_hcd ohci_hcd Pid: 4378, CPU 0, comm: sadc psr : 00001210085a2010 ifs : 8000000000000289 ip : [<a000000100482071>] Not tainted ip is at check_modem_status+0xf1/0x360 Call Trace: [<a000000100013940>] show_stack+0x40/0xa0 [<a0000001000145a0>] show_regs+0x840/0x880 [<a0000001000368e0>] die+0x1c0/0x2c0 [<a000000100036a30>] die_if_kernel+0x50/0x80 [<a000000100037c40>] ia64_fault+0x11e0/0x1300 [<a00000010000bdc0>] ia64_leave_kernel+0x0/0x280 [<a000000100482070>] check_modem_status+0xf0/0x360 [<a000000100482300>] serial8250_get_mctrl+0x20/0xa0 [<a000000100478170>] uart_read_proc+0x250/0x860 [<a0000001001c16d0>] proc_file_read+0x1d0/0x4c0 [<a0000001001394b0>] vfs_read+0x1b0/0x300 [<a000000100139cd0>] sys_read+0x70/0xe0 [<a00000010000bc20>] ia64_ret_from_syscall+0x0/0x20 [<a000000000010620>] __kernel_syscall_via_break+0x0/0x20 Fix the possible NULL pointer access in check_modem_status() in 8250.c. The check_modem_status() would access 'info' member of uart_port structure, but it is not initialized before uart_open() is called. The check_modem_status() can be called through /proc/tty/driver/serial before uart_open() is called. Signed-off-by:Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Taku Izumi <izumi2005@soft.fujitsu.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: <stable@kernel.org> Signed-off-by:
-
David Rientjes authored
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task. When finding other threads that share an mm with that task, we need to kill those individual threads and not the same one. (Bug introduced by f2a2a710) Acked-by:
Christoph Lameter <clameter@engr.sgi.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Andrew Morton <akpm@osdl.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
David Rientjes <rientjes@google.com> Signed-off-by:
-
- 23 Apr, 2007 3 commits
-
-
S.Çağlar Onur authored
USRobotics Wireless Adapter (Model 5423) works well with current zd1211rw driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7). It just needs its ID added to the list of devices. Signed-off-by:
S.Çağlar Onur <caglar@pardus.org.tr> Signed-off-by:
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SUNHME]: Fix module unload. [SUNLANCE]: Fix module unload. [SUNQE]: Fix MAC address assignment. [SBUS] vfc_dev.c: kzalloc
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [PPP]: Fix skbuff.c:BUG due incorrect logic in process_input_packet()
-
- 21 Apr, 2007 13 commits
-
-
Marcel van Nies authored
Signed-off-by:
Marcel van Nies <morcles@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marcel van Nies authored
Signed-off-by:
-
Marcel van Nies authored
The MAC address assignment at module loading is simply forgotten. The bug at module unloading is caused by an incorrect call. The bug at module unloading does not only happen for sunqe, sunlance and sunhme (sbus) suffer from it too. I've tested this on my SS20. Signed-off-by:
-
vignesh babu authored
Replacing kmalloc/memset combination with kzalloc. Signed-off-by:
vignesh babu <vignesh.babu@wipro.com> Signed-off-by:
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6: ide/Kconfig: add missing range check for IDE_MAX_HWIFS hpt366: fix kernel oops with HPT302N ide/pci/delkin_cb.c: add new PCI ID
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Fix wrong checksum for split TCP packets on 64-bit MIPS [MIPS] Fix BUG(), BUG_ON() handling [MIPS] Retry {save,restore}_fp_context if failed in atomic context. [MIPS] Disallow CpU exception in kernel again. [MIPS] Add missing silicon revisions for BCM112x
-
Trond Myklebust authored
Fix a regression due to the patch "NFS: disconnect before retrying NFSv4 requests over TCP" The assumption made in xprt_transmit() that the condition "req->rq_bytes_sent == 0 and request is on the receive list" should imply that we're dealing with a retransmission is false. Firstly, it may simply happen that the socket send queue was full at the time the request was initially sent through xprt_transmit(). Secondly, doing this for each request that was retransmitted implies that we disconnect and reconnect for _every_ request that happened to be retransmitted irrespective of whether or not a disconnection has already occurred. Fix is to move this logic into the call_status request timeout handler. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
Protect nfs_set_page_dirty() against races with nfs_inode_add_request. Signed-off-by:
-
Trond Myklebust authored
Redirtying a request that is already marked for commit will screw up the accounting for NR_UNSTABLE_NFS as well as nfs_i.ncommit. Ensure that all requests on the commit queue are labelled with the PG_NEED_COMMIT flag, and avoid moving them onto the dirty list inside nfs_page_mark_flush(). Also inline nfs_mark_request_dirty() into nfs_page_mark_flush() for atomicity reasons. Avoid dropping the spinlock until we're done marking the request in the radix tree and have added it to the ->dirty list. Signed-off-by:
-
Trond Myklebust authored
Ensure that we don't release the PG_writeback lock until after the page has either been redirtied, or queued on the nfs_inode 'commit' list. Signed-off-by:
-
Trond Myklebust authored
Get rid of the inlined #ifdefs. Signed-off-by:
-
Dave Jones authored
Support for Longhaul ver. 2 broke driver for VIA C3 Eden 600MHz with Samuel 2 core. Processor is not able to switch frequency anymore. I don't know much about this issue at the moment, but until (if ever) I will know why, this part should be reversed. Signed-off-by:
Rafal Bilski <rafalbilski@interia.pl> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Jens Axboe authored
We have a 10-15% performance regression for sequential writes on TCQ/NCQ enabled drives in 2.6.21-rcX after the CFQ update went in. It has been reported by Valerie Clement <valerie.clement@bull.net> and the Intel testing folks. The regression is because of CFQ's now more aggressive queue control, limiting the depth available to the device. This patches fixes that regression by allowing a greater depth when only one queue is busy. It has been tested to not impact sync-vs-async workloads too much - we still do a lot better than 2.6.20. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
- 20 Apr, 2007 10 commits
-
-
Bartlomiej Zolnierkiewicz authored
ide_hwif_to_major[] has only 10 entries as there are 10 major numbers reserved for IDE (if somebody needs more it shouldn't be hard to fix). Signed-off-by:Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
Sergei Shtylyov authored
The driver crashes the kernel on HPT302N chips due to the missing initializer for 'hpt302n.settings' having been unfortunately overlooked so far. :-< Much thanks to Mike Mattie for pin-pointing the reason of crash. Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Mark Lord authored
Add PCI ID for a newer variant of cardbus CF/IDE adapter card. Signed-off-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
-
Dave Johnson authored
I've traced down an off-by-one TCP checksum calculation error under the following conditions: 1) The TCP code needs to split a full-sized packet due to a reduced MSS (typically due to the addition of TCP options mid-stream like SACK). _AND_ 2) The checksum of the 2nd fragment is larger than the checksum of the original packet. After subtraction this results in a checksum for the 1st fragment with bits 16..31 set to 1. (this is ok) _AND_ 3) The checksum of the 1st fragment's TCP header plus the previously 32bit checksum of the 1st fragment DOES NOT cause a 32bit overflow when added together. This results in a checksum of the TCP header plus TCP data that still has the upper 16 bits as 1's. _THEN_ 4) The TCP+data checksum is added to the checksum of the pseudo IP header with csum_tcpudp_nofold() incorrectly (the bug). The problem is the checksum of the TCP+data is passed to csum_tcpudp_nofold() as an 32bit unsigned value, however the assembly code acts on it as if it is a 64bit unsigned value. This causes an incorrect 32->64bit extension if the sum has bit 31 set. The resulting checksum is off by one. This problems is data and TCP header dependent due to #2 and #3 above so it doesn't occur on every TCP packet split. Signed-off-by:Dave Johnson <djohnson+linux-mips@sw.starentnetworks.com> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Atsushi Nemoto authored
With commit 63dc68a8, kernel can not handle BUG() and BUG_ON() properly since get_user() returns false for kernel code. Use __get_user() to skip unnecessary access_ok(). This patch also make BRK_BUG code encoded in the TNE instruction. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
-
Atsushi Nemoto authored
The save_fp_context()/restore_fp_context() might sleep on accessing user stack and therefore might lose FPU ownership in middle of them. If these function failed due to "in_atomic" test in do_page_fault, touch the sigcontext area in non-atomic context and retry these save/restore operation. This is a replacement of a (broken) fix which was titled "Allow CpU exception in kernel partially". Signed-off-by:
-
Atsushi Nemoto authored
The commit 4d40bff7110e9e1a97ff8c01bdd6350e9867cc10 ("Allow CpU exception in kernel partially") was broken. The commit was to fix theoretical problem but broke usual case. Revert it for now. Signed-off-by: -
Mark Mason authored
Recent versions of the BCM112X processors aren't recognized by Linux (preventing Linux from booting on those processors). This patch adds support for those that are missing. Signed-off-by:
Mark Mason <mason@broadcom.com> Signed-off-by:
-
Linus Torvalds authored
This reverts commit 60cba200. It's been linked to lockups of the e1000 hardware, see for example https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 but it's likely that the commit itself is not really introducing the bug, but just allowing an unrelated problem to rear its ugly head (ie one current working theory is that the code exposes us to a hardware race condition by decreasing the amount of time we spend in each NAPI poll cycle). We'll revert it until root cause is known. Intel has a repeatable reproduction on two different machines and bus traces of the hardware doing something bad. Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: David S. Miller <davem@davemloft.net> Cc: Greg KH <gregkh@suse.de> Cc: Dave Jones <davej@redhat.com> Cc: Auke Kok <auke-jan.h.kok@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: pata_sis: Fix oops on boot
-
- 19 Apr, 2007 2 commits
-
-
Alan Cox authored
A small number of SiS setups require special handling (not many judging by how long this dumb bug survived). A couple of Fedora 7 devel testers hit an Oops on pata_sis loading which is caused by terminal confusion between chipset as 'the chipset we have found' and chipset as 'array iterator' Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Paul Mackerras authored
From: Paul Mackerras <paulus@samba.org> This fixes: Subject: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 process_input_packet() treats the case where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and the RFC does envision the possibility of receiving frames where the control field has values other than 0x03. Signed-off-by:
-
