- 09 Jun, 2009 1 commit
-
-
NeilBrown authored
mddev->raid_disks can be changed and any time by a request from user-space. It is a suggestion as to what number of raid_disks is desired. conf->raid_disks can only be changed by the raid5 module with suitable locks in place. It is a statement as to the current number of raid_disks. There are two places where the latter should be used, but the former is used. This can lead to a crash when reshaping an array. This patch changes to mddev-> to conf-> Signed-off-by: NeilBrown <neilb@suse.de>
-
- 06 Jun, 2009 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: x86/pci: fix mmconfig detection with 32bit near 4g PCI: use fixed-up device class when configuring device
-
Hugh Dickins authored
CONFIG_IMA=y inode activity leaks iint_cache and radix_tree_node objects until the system runs out of memory. Nowhere is calling ima_inode_free() a.k.a. ima_iint_delete(). Fix that by calling it from destroy_inode(). Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: ext3/4 with synchronous writes gets wedged by Postfix Fix nobh_truncate_page() to not pass stack garbage to get_block()
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: [libata] pata_ali: Use IGN_SIMPLEX
-
Al Viro authored
OK, that's probably the easiest way to do that, as much as I don't like it... Since iget() et.al. will not accept I_FREEING (will wait to go away and restart), and since we'd better have serialization between new/free on fs data structures anyway, we can afford simply skipping I_FREEING et.al. in insert_inode_locked(). We do that from new_inode, so it won't race with free_inode in any interesting ways and it won't race with iget (of any origin; nfsd or in case of fs corruption a lookup) since both still will wait for I_LOCK. Reviewed-by: "Theodore Ts'o" <tytso@mit.edu> Acked-by: Jan Kara <jack@suse.cz> Tested-by: David Watson <dbwatson@ukfsn.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Theodore Ts'o authored
The nobh_truncate_page() function is used by ext2, exofs, and jfs. Of these three, only ext2 and jfs's get_block() function pays attention to bh->b_size --- which is normally always the filesystem blocksize except when the get_block() function is called by either mpage_readpage(), mpage_readpages(), or the direct I/O routines in fs/direct_io.c. Unfortunately, nobh_truncate_page() does not initialize map_bh before calling the filesystem-supplied get_block() function. So ext2 and jfs will try to calculate the number of blocks to map by taking stack garbage and shifting it left by inode->i_blkbits. This should be *mostly* harmless (except the filesystem will do some unnneeded work) unless the stack garbage is less than filesystem's blocksize, in which case maxblocks will be zero, and the attempt to find out whether or not the filesystem has a hole at a given logical block will fail, and the page cache entry might not get zero'ed out. Also if the stack garbage in in map_bh->state happens to have the BH_Mapped bit set, there could be an attempt to call readpage() on a non-existent page, which could cause nobh_truncate_page() to return an error when it should not. Fix this by initializing map_bh->state and map_bh->size. Fortunately, it's probably fairly unlikely that ext2 and jfs users mount with nobh these days. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
- 05 Jun, 2009 15 commits
-
-
Alan Cox authored
Some ALi devices report simplex if they have been disabled and re-enabled, and restoring the byte does not work. Ignore it - the needed supporting logic is already present for the SATA ULi ports. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstableLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable: Btrfs: Fix oops and use after free during space balancing Btrfs: set device->total_disk_bytes when adding new device
-
Kevin Hilman authored
DaVinci clock support has been updated in mainline. Update clock names accordingly. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: ata_piix: Add HP Compaq nc6000 to the broken poweroff list ahci: add warning messages for hp laptops with broken suspend pata_efar: fix PIO2 underclocking pata_legacy: wait for async probing
-
Ville Syrjala authored
HP Compaq nc6000 suffers from the double disk spindown issue. Add it to the broken poweroff DMI list. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Tejun Heo authored
Harddisks on HP dv[4-6] and HDX18 fail to come online after resume on earlier BIOSen. Fortunately, HP recently released BIOS updates for all machines to fix the issue. Detect old BIOSen, warn the user to update BIOS on boot and suspend attempts and fail suspend. Kudos to all the bug reporters. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: kernel.org@epperson.homelinux.net Cc: emisca@gmail.com Cc: Gadi Cohen <dragon@wastelands.net> Cc: Paul Swanson <paul@procursa.com> Cc: s@ourada.org Cc: Trevor Davenport <trevor.davenport@gmail.com> Cc: corruptor1972 <steven_tierney@yahoo.co.uk> Cc: Victoria Wilson <mail@vwilson.co.uk> Cc: khiraly <khiraly.list@gmail.com> Cc: Sean <wollombi@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Sergei Shtylyov authored
Fix the PIO mode 2 using mode 0 timings -- this driver should enable the fast timing bank starting with PIO2, just like the PIIX/ICH drivers do. Also, fix/rephrase some comments while at it. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
James Bottomley authored
The basic problem here that pata_legacy attaches the host, sees if it found any devices and detaches it if none were found. With async probing, it's not waiting until discovery is finished before deciding it has no devices and trying the detach leading to this warning: ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14 ------------[ cut here ]------------ WARNING: at drivers/ata/libata-core.c:6222 ata_host_detach+0x75/0x90() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.30-rc7 #1 Call Trace: [<c01fbb05>] ? ata_host_detach+0x75/0x90 [<c01fbb05>] ? ata_host_detach+0x75/0x90 [<c01139b5>] ? warn_slowpath_common+0x45/0x80 [<c01139fa>] ? warn_slowpath_null+0xa/0x10 [<c01fbb05>] ? ata_host_detach+0x75/0x90 [<c02f40e0>] ? legacy_init+0x44e/0x87f [<c02f3c92>] ? legacy_init+0x0/0x87f [<c0101021>] ? _stext+0x21/0x140 [<c01890ff>] ? proc_register+0x2f/0x190 [<c018938c>] ? create_proc_entry+0x5c/0xc0 [<c0135ebe>] ? register_irq_proc+0x6e/0x90 [<c02e6484>] ? kernel_init+0x6e/0xbf [<c02e6416>] ? kernel_init+0x0/0xbf [<c01031d7>] ? kernel_thread_helper+0x7/0x10 ---[ end trace ef1ee36e873ae3a0 ]--- Because it detaches before the probe is complete. One way to fix it would be to put an async_synchronize_full() before looking for devices, which this patch does. A better way might be to separate libata into its own domain and only wait for that. Reported-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds authored
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] powernow-k8: check space_id of _PCT registers to be FFH
-
Dave Jones authored
The powernow-k8 driver checks to see that the Performance Control/Status Registers are declared as FFH (functional fixed hardware) by the BIOS. However, this check got broken in the commit: 0e64a0c9 [CPUFREQ] checkpatch cleanups for powernow-k8 Fix based on an original patch from Naga Chumbalkar. Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Cc: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
-
Linus Torvalds authored
This reverts commit 6c51d1cf, which apparently causes DRI initialization failures on Radeons. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Requested-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Alan Cox authored
The ivtv stream buffers may be for receive or for send but the attached sg handle is always destined cpu->device. We flush it correctly but the allocation is wrongly done with the same type as the buffers. See bug: http://bugzilla.kernel.org/show_bug.cgi?id=13385 (Note this doesn't close the bug - it fixes the ivtv part and in turn the logging next shows up some rather alarming DMA sg list warnings in libata) Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
Commit 95a3540d ("ptrace_detach: the wrong wakeup breaks the ERESTARTxxx logic") removed the "extra" wake_up_process() from ptrace_detach(), but as Jan pointed out this breaks the compatibility. I believe the changelog is right and this wake_up() is wrong in many ways, but GDB assumes that ptrace(PTRACE_DETACH, child, 0, 0) always wakes up the tracee. Despite the fact this breaks SIGNAL_STOP_STOPPED/group_stop_count logic, and despite the fact this wake_up_process() can break another assumption: PTRACE_DETACH with SIGSTOP should leave the tracee in TASK_STOPPED case. Because the untraced child can dequeue SIGSTOP and call do_signal_stop() before ptrace_detach() calls wake_up_process(). Revert this change for now. We need some fixes even if we we want to keep the current behaviour, but these fixes are not for 2.6.30. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> Cc: Jan Kratochvil <jan.kratochvil@redhat.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Frysinger authored
The checking of CONFIG_FRAME_WARN in the top level Makefile forgot to actually derefence the variable thus leading to an always true check. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Andi Kleen <ak@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
The "trace || CLONE_PTRACE" check in tracehook_report_clone() is not right, - If the untraced task does clone(CLONE_PTRACE) the new child is not traced, we must not queue SIGSTOP. - If we forked the traced task, but the tracer exits and untraces both the forking task and the new child (after copy_process() drops tasklist_lock), we should not queue SIGSTOP too. Change the code to check task_ptrace() != 0 instead. This is still racy, but the race is harmless. We can race with another tracer attaching to this child, or the tracer can exit and detach in parallel. But giwen that we didn't do wake_up_new_task() yet, the child must have the pending SIGSTOP anyway. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 04 Jun, 2009 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intelLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: Remove a bad BUG_ON in the fence management code.
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm: ignore EDID with really tiny modes. drm: don't associate _DRM_DRIVER maps with a master drm/i915: intel_lvds.c fix section mismatch drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms. drm: set permissions on edid file to 0444 drm: add newlines to text sysfs files drm/radeon: fix ring free alignment calculations drm: fix irq naming for kms drivers.
-
Salman Qazi authored
While running 20 parallel instances of dd as follows: #!/bin/bash for i in `seq 1 20`; do dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 & done wait on a 16G machine, we noticed that rather than just killing the processes, the entire kernel went down. Stracing dd reveals that it first does an mmap2, which makes 1GB worth of zero page mappings. Then it performs a read on those pages from /dev/zero, and finally it performs a write. The machine died during the reads. Looking at the code, it was noticed that /dev/zero's read operation had been changed by 557ed1fa ("remove ZERO_PAGE") from giving zero page mappings to actually zeroing the page. The zeroing of the pages causes physical pages to be allocated to the process. But, when the process exhausts all the memory that it can, the kernel cannot kill it, as it is still in the kernel mode allocating more memory. Consequently, the kernel eventually crashes. To fix this, I propose that when a fatal signal is pending during /dev/zero read operation, we simply return and let the user process die. Signed-off-by: Salman Qazi <sqazi@google.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> [ Modified error return and comment trivially. - Linus] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Mason authored
The btrfs allocator uses list_for_each to walk the available block groups when searching for free blocks. It starts off with a hint to help find the best block group for a given allocation. The hint is resolved into a block group, but we don't properly check to make sure the block group we find isn't in the middle of being freed due to filesystem shrinking or balancing. If it is being freed, the list pointers in it are bogus and can't be trusted. But, the code happily goes along and uses them in the list_for_each loop, leading to all kinds of fun. The fix used here is to check to make sure the block group we find really is on the list before we use it. list_del_init is used when removing it from the list, so we can do a proper check. The allocation clustering code has a similar bug where it will trust the block group in the current free space cluster. If our allocation flags have changed (going from single spindle dup to raid1 for example) because the drives in the FS have changed, we're not allowed to use the old block group any more. The fix used here is to check the current cluster against the current allocation flags. Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
Rusty Russell authored
We don't set up the canary; let's disable stack protector on boot.c so we can get into lguest_init, then set it up. As a side effect, switch_to_new_gdt() sets up %fs for us properly too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Yan Zheng authored
It was not being properly initialized, and so the size saved to disk was not correct. Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
Eric Anholt authored
This could be triggered by a gtt mapping fault on 965 that decides to remove the fence from another object that happens to be active currently. Since the other object doesn't rely on the fence reg for its execution, we don't wait for it to finish. We'll soon be not waiting on 915 most of the time as well, so just drop the BUG_ON. Signed-off-by: Eric Anholt <eric@anholt.net>
-
Yinghai Lu authored
Pascal reported and bisected a commit: | x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case which broke one system system. ACPI: Using IOAPIC for interrupt routing PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 PCI: MCFG area at f0000000 reserved in ACPI motherboard resources PCI: Using MMCONFIG for extended config space it didn't have PCI: updated MCFG configuration 0: base f0000000 segment 0 buses 0 - 63 anymore, and try to use 0xf000000 - 0xffffffff for mmconfig For 32bit, mcfg_res->end could be 32bit only (if 64 resources aren't used) So use end - 1 to pass the value in mcfg->end to avoid overflow. We don't need to worry about the e820 path, they are always 64 bit. Reported-by: Pascal Terjan <pterjan@mandriva.com> Bisected-by: Pascal Terjan <pterjan@mandriva.com> Tested-by: Pascal Terjan <pterjan@mandriva.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Yu Zhao authored
The device class may be changed after the fixup, so re-read the class value from pci_dev when configuring the device. Otherwise some devices such as JMicron SATA controller won't work. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Reviewed-by: Grant Grundler <grundler@parisc-linux.org> Tested-by: Marc Dionne <marc.c.dionne@gmail.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Adam Jackson authored
Some EDIDs lie and report tiny modes that aren't possible. Ignore these modes. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 03 Jun, 2009 8 commits
-
-
Ben Skeggs authored
A driver will use the _DRM_DRIVER map flag to indicate that it wants to be responsible for removing the map itself, bypassing the DRM's automagic cleanup code. Since the multi-master changes this has been broken, resulting in some drivers having their registers unmapped before it's finished with them. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jaswinder Singh Rajput authored
intel_no_lvds[] does not require __initdata as it is used only by void intel_lvds_init(struct drm_device *dev). Signed-off-by: Jaswinder Singh Rajput <jaswinder@kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Keith Packard authored
Making the drm_crtc.c code recognize the DPMS property and invoke the connector->dpms function doesn't remove any capability from the driver while reducing code duplication. That just highlighted the problem with the existing DPMS functions which could turn off the connector, but failed to turn off any relevant crtcs. The new drm_helper_connector_dpms function manages all of that, using the drm_helper-specific crtc and encoder dpms functions, automatically computing the appropriate DPMS level for each object in the system. This fixes the current troubles in the i915 driver which left PLLs, pipes and planes running while in DPMS_OFF mode or even while they were unused. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Keith Packard authored
Without initializing the sysfs attributes for the edid file, it was created with mode 0, making it difficult for applications to use. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Keith Packard authored
The contents of various simple text files in sysfs should end with a newline to make them easier to read from the console. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
fd.o bz#21849 We were aligning to +16 dwords, instead of to the next 16dword boundary in the ring. Fix the calculation to go to the next 16dword boundary when space checking. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
allocating devname in the i915 driver was a hack originally and I forgot to figure out how to do this properly back then. So this is the cleaner version that just picks devname or driver name in the irq code. It removes the devname allocs from the i915 driver. Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Linus Torvalds authored
-