- 03 Jun, 2011 16 commits
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
* 'for-linus' of git://git.kernel.dk/linux-block: block: Use hlist_entry() for io_context.cic_list.first cfq-iosched: Remove bogus check in queue_fail path xen/blkback: potential null dereference in error handling xen/blkback: don't call vbd_size() if bd_disk is NULL block: blkdev_get() should access ->bd_disk only after success CFQ: Fix typo and remove unnecessary semicolon block: remove unwanted semicolons Revert "block: Remove extra discard_alignment from hd_struct." nbd: adjust 'max_part' according to part_shift nbd: limit module parameters to a sane value nbd: pass MSG_* flags to kernel_recvmsg() block: improve the bio_add_page() and bio_add_pc_page() descriptions
-
git://git.kernel.org/pub/scm/linux/kernel/git/vapier/blackfinLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/vapier/blackfin: Blackfin: strncpy: fix handling of zero lengths
-
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tileLinus Torvalds authored
* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: asm-generic/unistd.h: support sendmmsg syscall tile: enable CONFIG_BUGVERBOSE
-
git://git.infradead.org/ubifs-2.6Linus Torvalds authored
* 'linux-next' of git://git.infradead.org/ubifs-2.6: UBIFS: fix-up free space earlier UBIFS: intialize LPT earlier UBIFS: assert no fixup when writing a node UBIFS: fix clean znode counter corruption in error cases UBIFS: fix memory leak on error path UBIFS: fix shrinker object count reports UBIFS: fix recovery broken by the previous recovery fix UBIFS: amend ubifs_recover_leb interface UBIFS: introduce a "grouped" journal head flag UBIFS: supress false error messages
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-ktestLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-ktest: ktest: Ignore unset values of the minconfig in config_bisect ktest: Fix result of rebooting the kernel ktest: Fix off-by-one in config bisect result
-
Linus Torvalds authored
Merge branch 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 * 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: ARM: mach-shmobile: add DMAC clock definitions on SH7372 ARM: arch-shmobile: support SDHI card detection on mackerel, using a GPIO sh_mobile_meram: MERAM platform data for LCDC
-
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6Linus Torvalds authored
* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: dmaengine: shdma: fix a regression: initialise DMA channels for memcpy dmaengine: shdma: Fix up fallout from runtime PM changes. Revert "clocksource: sh_cmt: Runtime PM support" Revert "clocksource: sh_tmu: Runtime PM support" sh: Fix up asm-generic/ptrace.h fallout. sh64: Move from P1SEG to CAC_ADDR for consistent sync. sh64: asm/pgtable.h needs asm/mmu.h sh: asm/tlb.h needs linux/swap.h sh: mark DMA slave ID 0 as invalid sh: Update shmin to reflect PIO dependency. sh: arch/sh/kernel/process_32.c needs linux/prefetch.h. sh: add MMCIF runtime PM support on ecovec sh: switch ap325rxa to dynamically manage the platform camera
-
Linus Torvalds authored
This reverts commit ed0bd233. Since we reverted the TTY API change, we should revert the ASoC update to it too. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
This reverts commit b1c43f82. It was broken in so many ways, and results in random odd pty issues. It re-introduced the buggy schedule_work() in flush_to_ldisc() that can cause endless work-loops (see commit a5660b41: "tty: fix endless work loop when the buffer fills up"). It also used an "unsigned int" return value fo the ->receive_buf() function, but then made multiple functions return a negative error code, and didn't actually check for the error in the caller. And it didn't actually work at all. BenH bisected down odd tty behavior to it: "It looks like the patch is causing some major malfunctions of the X server for me, possibly related to PTYs. For example, cat'ing a large file in a gnome terminal hangs the kernel for -minutes- in a loop of what looks like flush_to_ldisc/workqueue code, (some ftrace data in the quoted bits further down). ... Some more data: It -looks- like what happens is that the flush_to_ldisc work queue entry constantly re-queues itself (because the PTY is full ?) and the workqueue thread will basically loop forver calling it without ever scheduling, thus starving the consumer process that could have emptied the PTY." which is pretty much exactly the problem we fixed in a5660b41. Milton Miller pointed out the 'unsigned int' issue. Reported-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by:
Milton Miller <miltonm@bga.com> Cc: Stefan Bigler <stefan.bigler@keymile.com> Cc: Toby Gray <toby.gray@realvnc.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Ben Gardiner authored
The free space fixup is currently initiated during mount after the call to ubifs_write_master() which results in a write to PEBs; this has been observed with the patch 'assert no fixup when writing a node' applied: Move the free space fixup on mount to before the calls to ubifs_recover_inl_heads() and ubifs_write_master(). This results in no assertions with the previously mentioned patch applied. Artem: tweaked the patch a bit Signed-off-by:
Ben Gardiner <bengardiner@nanometrics> Reviewed-by:
Matthew L. Creech <mlcreech@gmail.com> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
Ben Gardiner authored
The current 'mount_ubifs()' implementation does not initialize the LPT until the the master node is marked dirty. Move the LPT initialization to before marking the master node dirty. This is a preparation for the next patch which will move the free-space-fixup check to before marking the master node dirty, because we have to fix-up the free space before doing any writes. Artem: massaged the patch and commit message. Signed-off-by:
Ben Gardiner <bengardiner@nanometrics.ca> Reviewed-by:
Matthew L. Creech <mlcreech@gmail.com> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
Ben Gardiner authored
The current free space fixup can result in some writing to the UBI volume when the space_fixup flag is set. To catch instances where UBIFS is writing to the NAND while the space_fixup flag is set, add an assert to ubifs_write_node(). Artem: tweaked the patch, added similar assertion to the write buffer write path. Signed-off-by:
Ben Gardiner <bengardiner@nanometrics.ca> Reviewed-by:
Matthew L. Creech <mlcreech@gmail.com> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
Artem Bityutskiy authored
UBIFS maintains per-filesystem and global clean znode counters ('c->clean_zn_cnt' and 'ubifs_clean_zn_cnt'). It is important to maintain correct values there since the shrinker relies on 'ubifs_clean_zn_cnt'. However, in case of failures during commit the counters were corrupted. E.g., if a failure happens in the middle of 'write_index()', then some nodes in the commit list ('c->cnext') are marked as clean, and some are marked as dirty. And the 'ubifs_destroy_tnc_subtree()' frees does not retrun correct count, and we end up with non-zero 'c->clean_zn_cnt' when unmounting. This means that if we have 2 file-sytem and one of them fails, and we unmount it, 'ubifs_clean_zn_cnt' stays incorrect and confuses the shrinker. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
Artem Bityutskiy authored
UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write failure because it forgets to free the 'struct ubifs_dent_node *dent' object. Although the object is small, the alignment can make it large - e.g., 2KiB if the min. I/O unit is 2KiB. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Cc: stable@kernel.org
-
Artem Bityutskiy authored
Sometimes VM asks the shrinker to return amount of objects it can shrink, and we return the ubifs_clean_zn_cnt in that case. However, it is possible that this counter is negative for a short period of time, due to the way UBIFS TNC code updates it. And I can observe the following warnings sometimes: shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788 This patch makes sure UBIFS never returns negative count of objects. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Cc: stable@kernel.org
-
Steven Miao authored
The jump to 4f will cause the NUL padding loop to run at least one time, so if string length is zero just jump to the end. Otherwise we wrongly write one NUL byte when size==0. Signed-off-by:
Steven Miao <realmz6@gmail.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org>
-
- 02 Jun, 2011 9 commits
-
-
Chris Metcalf authored
Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Acked-by:
Arnd Bergmann <arnd@arndb.de>
-
Steven Rostedt authored
By ignoring the unset values of the minconfig in deciding what to test in the config_bisect can cause the problem config from being tested too. Just do not test the configs that are set in the minconfig. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Steven Rostedt authored
The command that is called that reboots the kernel may fail but the return code is not passed back to the ktest.pl script. This is because a ';' is used between the two commands and if the second command fails, only the first command's return code is returned. Using a '&&' between the two commands fixes this. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Steven Rostedt authored
Because in perl the array size returned by $#arr, is the last index and not the actually size of the array, we end the config bisect early, thinking there is only one config left when there are in fact two. Thus the result has a 50% chance of picking the correct config that caused the problem. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Jens Axboe authored
Merge branch 'for-jens/xen-blkback.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-linus
-
Paul Bolle authored
list_entry() and hlist_entry() are both simply aliases for container_of(), but since io_context.cic_list.first is an hlist_node one should at least use the correct alias. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com>
-
Paul Bolle authored
queue_fail can only be reached if cic is NULL, so its check for cic must be bogus. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com>
-
Guennadi Liakhovetski authored
These definitions are needed to let the runtime PM subsystem turn off DMAC clocks, when it is suspended by the driver. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Paul Mundt <lethal@linux-sh.org>
-
Guennadi Liakhovetski authored
A recent patch has introduced a regression, where repeating a memcpy DMA test with shdma module unloading between them skips the DMA channel configuration. Fix this regression by always configuring the channel during its allocation. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Paul Mundt <lethal@linux-sh.org>
-
- 01 Jun, 2011 15 commits
-
-
Linus Torvalds authored
This reverts commit a197b59a. As rmk says: "Commit a197b59a (mm: fail GFP_DMA allocations when ZONE_DMA is not configured) is causing regressions on ARM with various drivers which use GFP_DMA. The behaviour up until now has been to silently ignore that flag when CONFIG_ZONE_DMA is not enabled, and to allocate from the normal zone. However, as a result of the above commit, such allocations now fail which causes drivers to fail. These are regressions compared to the previous kernel version." so just revert it. Requested-by:
Russell King <linux@arm.linux.org.uk> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.infradead.org/iommu-2.6Linus Torvalds authored
* git://git.infradead.org/iommu-2.6: intel-iommu: Fix off-by-one in RMRR setup intel-iommu: Add domain check in domain_remove_one_dev_info intel-iommu: Remove Host Bridge devices from identity mapping intel-iommu: Use coherent DMA mask when requested intel-iommu: Dont cache iova above 32bit intel-iommu: Speed up processing of the identity_mapping function intel-iommu: Check for identity mapping candidate using system dma mask intel-iommu: Only unlink device domains from iommu intel-iommu: Enable super page (2MiB, 1GiB, etc.) support intel-iommu: Flush unmaps at domain_exit intel-iommu: Remove obsolete comment from detect_intel_iommu intel-iommu: fix VT-d PMR disable for TXT on S3 resume
-
Linus Torvalds authored
Jens' back-merge commit 698567f3 ("Merge commit 'v2.6.39' into for-2.6.40/core") was incorrectly done, and re-introduced the DISK_EVENT_MEDIA_CHANGE lines that had been removed earlier in commits - 9fd097b1 ("block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers") - 7eec77a1 ("ide: unexport DISK_EVENT_MEDIA_CHANGE for ide-gd and ide-cd") because of conflicts with the "g->flags" updates near-by by commit d4dc210f ("block: don't block events on excl write for non-optical devices") As a result, we re-introduced the hanging behavior due to infinite disk media change reports. Tssk, tssk, people! Don't do back-merges at all, and *definitely* don't do them to hide merge conflicts from me - especially as I'm likely better at merging them than you are, since I do so many merges. Reported-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Metcalf authored
Trivial config change to enable backtraces on panic. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com>
-
Dan Carpenter authored
blkbk->pending_pages can be NULL here so I added a check for it. Signed-off-by:
Dan Carpenter <error27@gmail.com> [v1: Redid the loop a bit] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Laszlo Ersek authored
...because vbd_size() dereferences bd_disk if bd_part is NULL. Signed-off-by: Laszlo Ersek<lersek@redhat.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
git://git.infradead.org/mtd-2.6Linus Torvalds authored
* git://git.infradead.org/mtd-2.6: mtd: fix physmap.h warnings
-
David Woodhouse authored
We were mapping an extra byte (and hence usually an extra page): iommu_prepare_identity_map() expects to be given an 'end' argument which is the last byte to be mapped; not the first byte *not* to be mapped. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Mike Habeck authored
The comment in domain_remove_one_dev_info() states "No need to compare PCI domain; it has to be the same". But for the si_domain that isn't going to be true, as it consists of all the PCI devices that are identity mapped thus multiple PCI domains can be in si_domain. The code needs to validate the PCI domain too. Signed-off-by:
Mike Habeck <habeck@sgi.com> Signed-off-by:
Mike Travis <travis@sgi.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Mike Travis authored
When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices that do not use the IOMMU causes a kernel panic. Fix that by not inserting those devices into the si_domain. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Mike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Mike Travis authored
The __intel_map_single function is not honoring the passed in DMA mask. This results in not using the coherent DMA mask when called from intel_alloc_coherent(). Signed-off-by:
Mike Travis <travis@sgi.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Reviewed-by:
Mike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Chris Wright authored
Mike Travis and Mike Habeck reported an issue where iova allocation would return a range that was larger than a device's dma mask. https://lkml.org/lkml/2011/3/29/423 The dmar initialization code will reserve all PCI MMIO regions and copy those reservations into a domain specific iova tree. It is possible for one of those regions to be above the dma mask of a device. It is typical to allocate iovas with a 32bit mask (despite device's dma mask possibly being larger) and cache the result until it exhausts the lower 32bit address space. Freeing the iova range that is >= the last iova in the lower 32bit range when there is still an iova above the 32bit range will corrupt the cached iova by pointing it to a region that is above 32bit. If that region is also larger than the device's dma mask, a subsequent allocation will return an unusable iova and cause dma failure. Simply don't cache an iova that is above the 32bit caching boundary. Reported-by:
Mike Travis <travis@sgi.com> Reported-by:
Mike Habeck <habeck@sgi.com> Cc: stable@kernel.org Acked-by:
Mike Travis <travis@sgi.com> Tested-by:
Mike Habeck <habeck@sgi.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Mike Travis authored
When there are a large count of PCI devices, and the pass through option for iommu is set, much time is spent in the identity_mapping function hunting though the iommu domains to check if a specific device is "identity mapped". Speed up the function by checking the cached info to see if it's mapped to the static identity domain. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Mike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Chris Wright authored
The identity mapping code appears to make the assumption that if the devices dma_mask is greater than 32bits the device can use identity mapping. But that is not true: take the case where we have a 40bit device in a 44bit architecture. The device can potentially receive a physical address that it will truncate and cause incorrect addresses to be used. Instead check to see if the device's dma_mask is large enough to address the system's dma_mask. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Mike Habeck <habeck@sgi.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Alex Williamson authored
Commit a97590e5 added unlinking domains from iommus to reciprocate the iommu from domains unlinking that was already done. We actually want to only do this for device domains and never for the static identity map domain or VM domains. The SI domain is special and never freed, while VM domain->id lives in their own special address space, separate from iommu->domain_ids. In the current code, a VM can get domain->id zero, then mark that domain unused when unbound from pci-stub. This leads to DMAR write faults when the device is re-bound to the host driver. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Cc: stable@kernel.org Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-