- 19 4月, 2006 19 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Yoichi Yuasa 提交于
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Linus Torvalds 提交于
Came up through a quick grep for other cases similar to the ftruncate() one in commit 0a489cb3. Also, add a comment, so that people who read the code understand why we do what looks like a no-op. (Again, this won't actually matter to any sane user, since libc will save and restore the register gcc stomps on, but it's still wrong to stomp on it) Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
Gcc thinks it owns the incoming argument stack, but that's not true for "asmlinkage" functions, and it corrupts the caller-set-up argument stack when it pushes the third argument onto the stack. Which can result in %ebx getting corrupted in user space. Now, normally nobody sane would ever notice, since libc will save and restore %ebx anyway over the system call, but it's still wrong. I'd much rather have "asmlinkage" tell gcc directly that it doesn't own the stack, but no such attribute exists, so we're stuck with our hacky manual "prevent_tail_call()" macro once more (we've had the same issue before with sys_waitpid() and sys_wait4()). Thanks to Hans-Werner Hilse <hilse@sub.uni-goettingen.de> for reporting the issue and testing the fix. Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6由 Linus Torvalds 提交于
* 'drm-patches' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm: Fix further issues in drivers/char/drm/via_irq.c drivers/char/drm/drm_memory.c: possible cleanups drm: deline a few large inlines in DRM code drm: remove master setting from add/remove context drm: drm_pci needs dma-mapping.h [PATCH] drm: Fix issue reported by Coverity in drivers/char/drm/via_irq.c
-
由 Andi Kleen 提交于
Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
tee was already there for some reason for native 64bit, but sys_sync_file_range was missing. Also add it to the compat layer. Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
Needed for some big Opteron systems to compute a numa hash function They have more than 12 bits significant address. TBD switch this over to dynamic allocation or use better hash Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Vivek Goyal 提交于
o Start booting into the capture kernel after an Oops if system is in a unrecoverable state. System will boot into the capture kernel, if one is pre-loaded by the user, and capture the kernel core dump. o One of the following conditions should be true to trigger the booting of capture kernel. - panic_on_oops is set. - pid of current thread is 0 - pid of current thread is 1 - Oops happened inside interrupt context. Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
The patch I submitted earlier to fix disabled LAPIC handling in ACPI was mismerged for some reason I still don't quite understand. Parts of it was applied to the wrong function. This patch fixes it up. Cc: len.brown@intel.com Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andi Kleen 提交于
Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
git://brick.kernel.dk/data/git/linux-2.6-block由 Linus Torvalds 提交于
* 'for-linus' of git://brick.kernel.dk/data/git/linux-2.6-block: [PATCH] cfq: Further rbtree traversal and cfq_exit_queue() race fix [PATCH 2/2] cfq: fix cic's rbtree traversal [PATCH 1/2] iosched: fix typo and barrier()
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge由 Linus Torvalds 提交于
* git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge: powerpc: Use correct sequence for putting CPU into nap mode [PATCH] spufs: fix context-switch decrementer code [PATCH] powerpc32: Set cpu explicitly in kernel compiles [PATCH] powerpc/pseries: bugfix: balance calls to pci_device_put [PATCH] powerpc: Fix machine detection in prom_init.c [PATCH] ppc32: Fix string comparing in platform_notify_map [PATCH] powerpc: Avoid __initcall warnings [PATCH] powerpc: Ensure runlatch is off in the idle loop powerpc: Fix CHRP booting - needs a define_machine call powerpc: iSeries has only 256 IRQs
-
由 OGAWA Hirofumi 提交于
In current code, we are re-reading cic->key after dead cic->key check. So, in theory, it may really re-read *after* cfq_exit_queue() seted NULL. To avoid race, we copy it to stack, then use it. With this change, I guess gcc will assign cic->key to a register or stack, and it wouldn't be re-readed. Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: NJens Axboe <axboe@suse.de>
-
- 18 4月, 2006 16 次提交
-
-
由 Paul Mackerras 提交于
We weren't using the recommended sequence for putting the CPU into nap mode. When I changed the idle loop, for some reason 7447A cpus started hanging when we put them into nap mode. Changing to the recommended sequence fixes that. The complexity here is that the recommended sequence is a loop that keeps putting the cpu back into nap mode. Clearly we need some way to break out of the loop when an interrupt (external interrupt, decrementer, performance monitor) occurs. Here we use a bit in the thread_info struct to indicate that we need this, and the exception entry code notices this and arranges for the exception to return to the value in the link register, thus breaking out of the loop. We use a new `local_flags' field in the thread_info which we can alter without needing to use an atomic update sequence. The PPC970 has the same recommended sequence, so we do the same thing there too. This also fixes a bug in the kernel stack overflow handling code on 32-bit, since it was causing a value that we needed in a register to get trashed. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Jayachandran C 提交于
Fix de-reference of 'dev_priv' before NULL check. Signed-off-by: NJayachandran C. <c.jayachandran@gmail.com> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@osdl.org>
-
由 Adrian Bunk 提交于
- #if 0 the following unused global function: - drm_ioremap_nocache() - make the following needlessly global functions static: - agp_remap() - drm_lookup_map() Signed-off-by: NAdrian Bunk <bunk@stusta.de> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@osdl.org>
-
由 OGAWA Hirofumi 提交于
When queue dies, we set cic->key=NULL as dead mark. So, when we traverse a rbtree, we must check whether it's still valid key. if it was invalidated, drop it, then restart the traversal from top. Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: NJens Axboe <axboe@suse.de>
-
由 OGAWA Hirofumi 提交于
On rmmod path, cfq/as waits to make sure all io-contexts was freed. However, it's using complete(), not wait_for_completion(). I think barrier() is not enough in here. To avoid the following case, this patch replaces barrier() with smb_wmb(). cpu0 visibility cpu1 [ioc_gnone=NULL,ioc_count=1] ioc_gnone = &all_gone NULL,ioc_count=1 atomic_read(&ioc_count) NULL,ioc_count=1 wait_for_completion() NULL,ioc_count=0 atomic_sub_and_test() NULL,ioc_count=0 if ( && ioc_gone) [ioc_gone==NULL, so doesn't call complete()] &all_gone,ioc_count=0 Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: NJens Axboe <axboe@suse.de>
-
由 Alexey Kuznetsov 提交于
grow_ary() should not copy struct ipc_id_ary (it copies new->p, not new). Due to this, memcpy() src pointer could hit unmapped vmalloc page when near page boundary. Found during OpenVZ stress testing Signed-off-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: NKirill Korotaev <dev@openvz.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Hugh Dickins 提交于
madvise_remove needs to respect file and mmap protections. Signed-off-by: NHugh Dickins <hugh@veritas.com> [ Will the real CVE-2006-1524 stand up, please.. ] Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [IPV4]: ip_route_input panic fix
-
由 Linus Torvalds 提交于
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/stable-2.6: [PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524) [PATCH] cciss: bug fix for crash when running hpacucli [PATCH] ext3: Fix missed mutex unlock [PATCH] Fix block device symlink name [PATCH] isd200: limit to BLK_DEV_IDE
-
由 Stephen Hemminger 提交于
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388 The bug is caused by ip_route_input dereferencing skb->nh.protocol of the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing it). It only happens if the route requested is for a multicast IP address. Signed-off-by: NStephen Hemminger <shemminger@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hugh Dickins 提交于
I found that all of 2.4 and 2.6 have been letting mprotect give write permission to a readonly attachment of shared memory, whether or not IPC would give the caller that permission. SUS says "The behaviour of this function [mprotect] is unspecified if the mapping was not established by a call to mmap", but I don't think we can interpret that as allowing it to subvert IPC permissions. I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and the patch below reproduces that behaviour - mprotect cannot be used to add write permission to a shared memory segment attached readonly. This patch is simple, and I'm sure it's what we should have done in 2.4.0: if you want to go on to switch write permission on and off with mprotect, just don't attach the segment readonly in the first place. However, we could have accumulated apps which attach readonly (even though they would be permitted to attach read/write), and which subsequently use mprotect to switch write permission on and off: it's not unreasonable. I was going to add a second ipcperms check in do_shmat, to check for writable when readonly, and if not writable find_vma and clear VM_MAYWRITE. But security_ipc_permission might do auditing, and it seems wrong to report an attempt for write permission when there has been none. Or we could flag the vma as SHM, note the shmid or shp in vm_private_data, and then get mprotect to check. But the patch below is a lot simpler: I'd rather stick with it, if we can convince ourselves somehow that it'll be safe. Signed-off-by: NHugh Dickins <hugh@veritas.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Mike Miller 提交于
Fix a crash when running hpacucli with multiple logical volumes on a cciss controller. We were not properly initializing the disk->queue and causing a fault. Thanks to Hasso Tepper for reporting the problem. Thanks to Steve Cameron for root causing the problem. Most of the patch just moves things around. The fix is a one-liner. Signed-off-by: NMike Miller <mike.miller@hp.com> Signed-off-by: NStephen Cameron <steve.cameron@hp.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Ananiev, Leonid I 提交于
Missed unlock_super()call is added in error condition code path. Signed-off-by: NLeonid Ananiev <leonid.i.ananiev@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Stephen Rothwell 提交于
As noted further on the this file, some block devices have a / in their name, so fix the "block:..." symlink name the same as the /sys/block name. Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Randy Dunlap 提交于
Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE are set to (y, m) since isd200 calls ide_fix_driveid() in the BLK_DEV_IDE code. Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 David S. Miller 提交于
SYM2 driver uses it. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 4月, 2006 3 次提交
-
-
由 Linus Torvalds 提交于
* master.kernel.org:/home/rmk/linux-2.6-serial: [SERIAL] Update serial driver documentation
-
由 Linus Torvalds 提交于
* master.kernel.org:/home/rmk/linux-2.6-arm: [ARM] 3477/1: ARM EABI: undefine removed syscalls [ARM] 3475/1: S3C2410: fix spelling mistake in SMDK partition table [ARM] 3474/1: S3C2440: USB rate writes wrong var to CLKDIVN
-
由 Russell King 提交于
Improve serial driver documentation: - Remove CVS id. - Update pointer to reference driver documentation. - Add comments about new uart_write_console function. - Add TIOCM_LOOP modem control bit description. - Add commentry about enable_ms method being called multiple times. - Add commentry about startup/shutdown method calling. - Mention that dereferencing port->info after shutdown is invalid. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 15 4月, 2006 2 次提交
-
-
由 Nicolas Pitre 提交于
Patch from Nicolas Pitre Avoid confusion for libraries assuming that a given syscall is available when corresponding symbol is defined. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 David Brownell 提交于
The at91_cf driver got out of sync with certain changes in the PCMCIA layer, notably getting rid of some duplication of data ... causing the version merged to kernel.org to fail compiling. This patch gives the at91_cf platform device a new iomem resource, using it so this new pcmcia scheme works. It also cleans up some whitepsace bugs that have accumulated over time (mostly too-long lines). Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-