summaryrefslogtreecommitdiffstats
path: root/samples (unfollow)
Commit message (Collapse)AuthorFilesLines
2011-08-19drm/i915: set GFX_MODE to pre-Ivybridge default value even on IvybridgeJesse Barnes2-0/+8
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that MI_FLUSH would flush the TLBs in addition to the rest of the caches indicated in the MI_FLUSH command. However starting with Ivybridge, the register defaults to 0x2800 out of reset, meaning that to invalidate the TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go back to the old default so things work. v2: don't forget to actually *clear* the new bit Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-08-19PCI: OF: Don't crash when bridge parent is NULL.David Daney1-1/+1
In pcibios_get_phb_of_node(), we will crash while booting if bus->bridge->parent is NULL. Check for this case and avoid dereferencing the NULL pointer. Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-08-19Revert "cfq: Remove special treatment for metadata rqs."Jens Axboe1-0/+18
We have a kernel build regression since 3.1-rc1, which is about 10% regression. The kernel source is in an ext3 filesystem. Alex Shi bisect it to commit: commit a07405b7802691d29ab3b23bdc76ee6d006aad0b Author: Justin TerAvest <teravest@google.com> Date: Sun Jul 10 22:09:19 2011 +0200 cfq: Remove special treatment for metadata rqs. Apparently this is caused by lack metadata preemption, where ext3/ext4 do use READ_META. I didn't see a way to fix the issue, so suggest reverting the patch. This reverts commit a07405b7802691d29ab3b23bdc76ee6d006aad0b. Reported-by: Alex Shi<alex.shi@intel.com> Reported-by: Shaohua Li<shaohua.li@intel.com> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-19sparc: fix array bounds error setting up PCIC NMI trapIan Campbell1-2/+2
CC arch/sparc/kernel/pcic.o arch/sparc/kernel/pcic.c: In function 'pcic_probe': arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds] cc1: all warnings being treated as errors I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear to be 4 instructions long and I presume from the usage that instructions are int sized. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-19drivers/ata/sata_dwc_460ex.c: add missing kfreeJulia Lawall1-8/+6
Currently, error handling code in this function calls the function sata_dwc_port_stop, but this function has essentially no effect if hsdevp has not been stored in ap, which is the case throughout this function. The only effect is to print a debugging message including ap->print_id. The code is rewritten to not call sata_dwc_port_stop, but instead to jump to a local label that prints the original error message and the print_id information. In the case where hsdevp has been already allocated (but not yet stored in ap), this value is freed as well. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @exists@ local idexpression x; statement S,S1; expression E; identifier fl; expression *ptr != NULL; @@ x = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...kfree(x)...+> } when any when != true x == NULL x->fl ...> ( if (x == NULL) S1 | if (...) { ... when != x when forall ( return \(0\|<+...x...+>\|ptr\); | * return ...; ) } ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2011-08-19ata: Add iMX pata supportArnaud Patard (Rtp)3-0/+263
Add basic support for pata on iMX. It has been tested only on imx51. SDMA support will probably be added later so this version supports only PIO. v2: - enable only when needed IORDY - use dev_get_drvdata v3: - add missing clk_put() calls - use platform_get_irq() - fix resume code to avoid disabling IORDY on resume v4: - Remove EXPERIMENTAL and switch to depends on ARCH_MXC - Use devm_kzalloc() - make clock a must-have - Use only 1 ioremap Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2011-08-19pata_via: disable ATAPI DMA on AVERATEC 3200Tejun Heo1-0/+18
On AVERATEC 3200, pata_via causes memory corruption with ATAPI DMA, which often leads to random kernel oops. The cause of the problem is not well understood yet and only small subset of machines using the controller seem affected. Blacklist ATAPI DMA on the machine. Signed-off-by: Tejun Heo <tj@kernel.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11426 Reported-and-tested-by: Jim Bray <jimsantelmo@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2011-08-19[libata] sata_sil: fix used-uninit warningJeff Garzik1-1/+1
Init 'serror' to silence the following warning: drivers/ata/sata_sil.c: In function ‘sil_interrupt’: drivers/ata/sata_sil.c:453:14: warning: ‘serror’ may be used uninitialized in this function [-Wuninitialized] This is not a 'can never happen' but is nonetheless extremely unlikely. The easiest and cleanest warning fix is simply to init the var, rather than worry about marking the var uninit-ok. Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2011-08-18irqdesc: fix new kernel-doc warningRandy Dunlap1-0/+1
Fix kernel-doc warning in irqdesc.c: Warning(kernel/irq/irqdesc.c:353): No description found for parameter 'owner' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-18i7core_edac: fixed typo in error count calculationMathias Krause1-1/+1
Based on a patch from the PaX Team, found during a clang analysis pass. Signed-off-by: Mathias Krause <minipli@googlemail.com> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: PaX Team <pageexec@freemail.hu> Cc: stable@kernel.org [v2.6.35+] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-18update cifs version to 1.75Steve French1-1/+1
Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-18[CIFS] possible memory corruption on mountSteve French1-1/+2
CIFS cleanup_volume_info_contents() looks like having a memory corruption problem. When UNCip is set to "&vol->UNC[2]" in cifs_parse_mount_options(), it should not be kfree()-ed in cleanup_volume_info_contents(). Introduced in commit b946845a9dc523c759cae2b6a0f6827486c3221a Signed-off-by: J.R. Okajima <hooanon05@yahoo.co.jp> Reviewed-by: Jeff Layton <jlayton@redhat.com> CC: Stable <stable@kernel.org> Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-18Btrfs: set i_size properly when fallocating and we alreadyJosef Bacik1-0/+14
xfstests exposed a problem with preallocate when it fallocates a range that already has an extent. We don't set the new i_size properly because we see that we already have an extent. This isn't right and we should update i_size if the space already exists. With this patch we now pass xfstests 075. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-18btrfs: unlock on error in btrfs_file_llseek()Dan Carpenter1-4/+8
There were some unlocks on error missing in a recent patch to btrfs_file_llseek(). Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-18btrfs: btrfs_permission's RO check shouldn't apply to device nodesJeff Mahoney1-4/+8
This patch tightens the read-only access checks in btrfs_permission to match the constraints in inode_permission. Currently, even though the device node itself will be unmodified, read-write access to device nodes is denied to when the device node resides on a read-only subvolume or a is a file that has been marked read-only by the btrfs conversion utility. With this patch applied, the check only affects regular files, directories, and symlinks. It also restructures the code a bit so that we don't duplicate the MAY_WRITE check for both tests. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17befs: Validate length of long symbolic links.Timo Warns1-9/+14
Signed-off-by: Timo Warns <warns@pre-sense.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-17mm: fix __page_to_pfn for a const struct page argumentIan Campbell2-4/+4
This allows the cast in lowmem_page_address (introduced as a warning fixup to 33dd4e0ec911 "mm: make some struct page's const") to be removed. Propagate const'ness to page_to_section() as well since it is required by __page_to_pfn. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Michel Lespinasse <walken@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-17mm: make HASHED_PAGE_VIRTUAL page_address' struct page argument const.Ian Campbell3-4/+4
Followup to 33dd4e0ec911 "mm: make some struct page's const" which missed the HASHED_PAGE_VIRTUAL case. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Michel Lespinasse <walken@google.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-17IB/iser: Support iSCSI PDU paddingOr Gerlitz2-4/+8
RFC3270 mandates that iSCSI PDUs are padded to the closest integer number of four byte words. Fix the iser code to support that on both the TX/RX flows. Signed-off-by: Or Gerlitz <ogerlitz@mellanox.co.il> Signed-off-by: Roland Dreier <roland@purestorage.com>
2011-08-17IBiser: Fix wrong mask when sizeof (dma_addr_t) > sizeof (unsigned long)Or Gerlitz1-1/+1
The code that prepares the SG associated with SCSI command for FMR was buggy for systems with DMA addresses that don't fit in unsigned long, e.g under the 32-bit based XenServer dom0 sizeof(dma_addr_t) is 8. Fix that by casting to unsigned long long a masking constant used by the code. This resolves a crash in iser_sg_to_page_vec on this system. Signed-off-by: Or Gerlitz <ogerlitz@mellanox.co.il> Signed-off-by: Roland Dreier <roland@purestorage.com>
2011-08-17fat: fat16 support maximum 4GB file/vol size as WinXP or 7.Namjae Jeon1-2/+1
FAT16 support maximum 4GB vol/file size with 64KB cluster size. Win NT/XP/7 increased the maximum cluster size to 64KB, and file/vol size increased 4GB also. Although increasing, the file size of linux FAT is still limited at 2GB. I found that it is limited by sb->maxbytes(0x7fffffff) when partition is formatted by FAT16. sb->s_maxbytes in fill_super should be set to 0xffffffff like fat32. Signed-off-by: Namjae Jeon <linkinjeon@gmail.com> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
2011-08-17fat: fix utf8 iocharset warning messageMihai Moldovan1-2/+2
The fat_msg function already formats the given message and appends a newline to it - we don't need to do this in the passed message string as well, or will end up with a blank line printed in the kernel log ring buffer. Also change the loglevel from error to warning. Signed-off-by: Mihai Moldovan <ionic@ionic.de> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
2011-08-17fat: fix build warningJonas Aberg1-1/+1
This fixes a compile warning (unititialized variable) in the fat filesystem code. Signed-off-by: Jonas Aberg <jonas.aberg@stericsson.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
2011-08-17Btrfs: truncate pages from clone ioctl target rangeSage Weil1-0/+4
We need to truncate page cache pages for the clone ioctl target range or else we'll confuse ourselves to no end. If the old data was cached, we used to still see it (until remount). If the page was partially updated we used to get a mix of old and new data. Signed-off-by: Sage Weil <sage@newdream.net> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: fix uninitialized sync_pendingMiao Xie1-1/+1
sync_pending is uninitialized before it be used, fix it. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: fix wrong free space informationMiao Xie1-5/+11
Btrfs subtracted the size of the allocated space twice when it allocated the space from the bitmap in the cluster, it broke the free space information and led to oops finally. And this patch also fixes the bug that ctl->free_space was subtracted without lock. Reported-by: Liu Bo <liubo2009@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17btrfs: memory leak in btrfs_add_inode_defrag()Dan Carpenter1-0/+2
We don't use the defrag struct on this path. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: use plain page_address() in header fields setget functionsLi Zefan1-4/+2
We've stopped using highmem for extent buffers. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: forced readonly when btrfs_drop_snapshot() failsTsutomu Itoh2-10/+16
The filesystem turns readonly instead of returning the error to the caller when detected error in btrfs_drop_snapshot(). and, because the caller doesn't check the error, the function type is changed to 'void'. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: check if there is enough space for balancing smarterliubo1-6/+35
When checking if there is enough space for balancing a block group, since we do not take raid types into consideration, we do not account corrent amounts of space that we needed. This makes us do some extra work before we get ENOSPC. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: fix a bug of balance on full multi-disk partitionsliubo1-4/+13
When balancing, we'll first try to shrink devices for some space, but if it is working on a full multi-disk partition with raid protection, we may encounter a bug, that is, while shrinking, total_bytes may be less than bytes_used, and btrfs may allocate a dev extent that accesses out of device's bounds. Then we will not be able to write or read the data which stores at the end of the device, and get the followings: device fsid 0939f071-7ea3-46c8-95df-f176d773bfb6 devid 1 transid 10 /dev/sdb5 Btrfs detected SSD devices, enabling SSD mode btrfs: relocating block group 476315648 flags 9 btrfs: found 4 extents attempt to access beyond end of device sdb5: rw=145, want=546176, limit=546147 attempt to access beyond end of device sdb5: rw=145, want=546304, limit=546147 attempt to access beyond end of device sdb5: rw=145, want=546432, limit=546147 attempt to access beyond end of device sdb5: rw=145, want=546560, limit=546147 attempt to access beyond end of device Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: fix an oops of log replayliubo1-4/+24
When btrfs recovers from a crash, it may hit the oops below: ------------[ cut here ]------------ kernel BUG at fs/btrfs/inode.c:4580! [...] RIP: 0010:[<ffffffffa03df251>] [<ffffffffa03df251>] btrfs_add_link+0x161/0x1c0 [btrfs] [...] Call Trace: [<ffffffffa03e7b31>] ? btrfs_inode_ref_index+0x31/0x80 [btrfs] [<ffffffffa04054e9>] add_inode_ref+0x319/0x3f0 [btrfs] [<ffffffffa0407087>] replay_one_buffer+0x2c7/0x390 [btrfs] [<ffffffffa040444a>] walk_down_log_tree+0x32a/0x480 [btrfs] [<ffffffffa0404695>] walk_log_tree+0xf5/0x240 [btrfs] [<ffffffffa0406cc0>] btrfs_recover_log_trees+0x250/0x350 [btrfs] [<ffffffffa0406dc0>] ? btrfs_recover_log_trees+0x350/0x350 [btrfs] [<ffffffffa03d18b2>] open_ctree+0x1442/0x17d0 [btrfs] [...] This comes from that while replaying an inode ref item, we forget to check those old conflicting DIR_ITEM and DIR_INDEX items in fs/file tree, then we will come to conflict corners which lead to BUG_ON(). Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> Tested-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-17Btrfs: detect wether a device supports discardJosef Bacik3-2/+29
We have a problem where if a user specifies discard but doesn't actually support it we will return EOPNOTSUPP from btrfs_discard_extent. This is a problem because this gets called (in a fashion) from the tree log recovery code, which has a nice little BUG_ON(ret) after it, which causes us to fail the tree log replay. So instead detect wether our devices support discard when we're adding them and then don't issue discards if we know that the device doesn't support it. And just for good measure set ret = 0 in btrfs_issue_discard just in case we still get EOPNOTSUPP so we don't screw anybody up like this again. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
2011-08-16IPoIB: Fix possible NULL dereference in ipoib_start_xmit()Bernd Schubert1-3/+5
Fix a bug introduced in 69cce1d14049 ("net: Abstract dst->neighbour accesses behind helpers.") where we might dereference skb_dst(skb) even if it is NULL, which causes: [ 240.944030] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [ 240.948007] IP: [<ffffffffa0366ce9>] ipoib_start_xmit+0x39/0x280 [ib_ipoib] [...] [ 240.948007] Call Trace: [ 240.948007] <IRQ> [ 240.948007] [<ffffffff812cd5e0>] dev_hard_start_xmit+0x2a0/0x590 [ 240.948007] [<ffffffff8131f680>] ? arp_create+0x70/0x200 [ 240.948007] [<ffffffff812e8e1f>] sch_direct_xmit+0xef/0x1c0 Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=41212 Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Signed-off-by: Roland Dreier <roland@purestorage.com>
2011-08-16KVM: uses TASKSTATS, depends on NETRandy Dunlap1-0/+2
CONFIG_TASKSTATS just had a change to use netlink, including a change to "depends on NET". Since "select" does not follow dependencies, KVM also needs to depend on NET to prevent build errors when CONFIG_NET is not enabled. Sample of the reported "undefined reference" build errors: taskstats.c:(.text+0x8f686): undefined reference to `nla_put' taskstats.c:(.text+0x8f721): undefined reference to `nla_reserve' taskstats.c:(.text+0x8f8fb): undefined reference to `init_net' taskstats.c:(.text+0x8f905): undefined reference to `netlink_unicast' taskstats.c:(.text+0x8f934): undefined reference to `kfree_skb' taskstats.c:(.text+0x8f9e9): undefined reference to `skb_clone' taskstats.c:(.text+0x90060): undefined reference to `__alloc_skb' taskstats.c:(.text+0x901e9): undefined reference to `skb_put' taskstats.c:(.init.text+0x4665): undefined reference to `genl_register_family' taskstats.c:(.init.text+0x4699): undefined reference to `genl_register_ops' taskstats.c:(.init.text+0x4710): undefined reference to `genl_unregister_ops' taskstats.c:(.init.text+0x471c): undefined reference to `genl_unregister_family' Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2011-08-16xen: self-balloon needs module.hRandy Dunlap1-0/+1
Fix build errors (found when CONFIG_SYSFS is not enabled): drivers/xen/xen-selfballoon.c:446: warning: data definition has no type or storage class drivers/xen/xen-selfballoon.c:446: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/xen/xen-selfballoon.c:446: warning: parameter names (without types) in function declaration drivers/xen/xen-selfballoon.c:485: error: expected declaration specifiers or '...' before string constant drivers/xen/xen-selfballoon.c:485: warning: data definition has no type or storage class drivers/xen/xen-selfballoon.c:485: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' drivers/xen/xen-selfballoon.c:485: warning: function declaration isn't a prototype Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-16gma500: kill MIPI interface typesAlan Cox6-9/+11
Kirill Shutemov found problems with the non-upstream IMG driver where the use of extra DRM encoder/connector types caused random crashes when the DRM layer tried to display their matching name. This removes the MIPI types matching the changes Pauli Nieminen made to the non upstream driver set. As Pauli points out: " MIPI (or DSI) is protocol specification on top of LVDS serial bus. That makes it resonable to call MIPI connectors and encoders LVDS." (and indeed they may also be HDMI convertors or similar when we want to report a more useful to end user result) Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-16cifs: demote cERROR in build_path_from_dentry to cFYIJeff Layton1-2/+2
Running the cthon tests on a recent kernel caused this message to pop occasionally: CIFS VFS: did not end path lookup where expected namelen is 0 Some added debugging showed that namelen and dfsplen were both 0 when this occurred. That means that the read_seqretry returned true. Assuming that the comment inside the if statement is true, this should be harmless and just means that we raced with a rename. If that is the case, then there's no need for alarm and we can demote this to cFYI. While we're at it, print the dfsplen too so that we can see what happened here if the message pops during debugging. Cc: stable@kernel.org Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2011-08-16regmap: using module facilities requires module.hStephen Rothwell1-0/+1
Commit b33f9cbd67ba ("regmap: Specify a module license") added a MODULES_LICENSE to this file without adding an include of module.h. module.h should have been included anyway, since this file has EXPORT_SYMBOLs as well. With the pending module.h split up, this would probably have caused build problems. Cc: Stephen Warren <swarren@nvidia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-16x86: fix mm/fault.c buildRandy Dunlap1-0/+1
arch/x86/mm/fault.c needs to include asm/vsyscall.h to fix a build error: arch/x86/mm/fault.c: In function '__bad_area_nosemaphore': arch/x86/mm/fault.c:728: error: 'VSYSCALL_START' undeclared (first use in this function) Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-08-15sparc64: Set HAVE_C_RECORDMCOUNTDavid S. Miller1-0/+1
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-15sparc32: unbreak arch_write_unlock()Mikael Pettersson1-2/+9
The sparc32 version of arch_write_unlock() is just a plain assignment. Unfortunately this allows the compiler to schedule side-effects in a protected region to occur after the HW-level unlock, which is broken. E.g., the following trivial test case gets miscompiled: #include <linux/spinlock.h> rwlock_t lock; int counter; void foo(void) { write_lock(&lock); ++counter; write_unlock(&lock); } Fixed by adding a compiler memory barrier to arch_write_unlock(). The sparc64 version combines the barrier and assignment into a single asm(), and implements the operation as a static inline, so that's what I did too. Compile-tested with sparc32_defconfig + CONFIG_SMP=y. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-15sparc64: remove unnecessary macros from spinlock_64.hMikael Pettersson1-6/+0
The sparc64 spinlock_64.h contains a number of operations defined first as static inline functions, and then as macros with the same names and parameters as the functions. Maybe this was needed at some point in the past, but now nothing seems to depend on these macros (checked with a recursive grep looking for ifdefs on these names). Other archs don't define these identity-macros. So this patch deletes these unnecessary macros. Compile-tested with sparc64_defconfig. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-15block: fix flush machinery for stacking drivers with differring flush flagsJeff Moyer4-6/+25
Commit ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae, block: reimplement FLUSH/FUA to support merge, introduced a performance regression when running any sort of fsyncing workload using dm-multipath and certain storage (in our case, an HP EVA). The test I ran was fs_mark, and it dropped from ~800 files/sec on ext4 to ~100 files/sec. It turns out that dm-multipath always advertised flush+fua support, and passed commands on down the stack, where those flags used to get stripped off. The above commit changed that behavior: static inline struct request *__elv_next_request(struct request_queue *q) { struct request *rq; while (1) { - while (!list_empty(&q->queue_head)) { + if (!list_empty(&q->queue_head)) { rq = list_entry_rq(q->queue_head.next); - if (!(rq->cmd_flags & (REQ_FLUSH | REQ_FUA)) || - (rq->cmd_flags & REQ_FLUSH_SEQ)) - return rq; - rq = blk_do_flush(q, rq); - if (rq) - return rq; + return rq; } Note that previously, a command would come in here, have REQ_FLUSH|REQ_FUA set, and then get handed off to blk_do_flush: struct request *blk_do_flush(struct request_queue *q, struct request *rq) { unsigned int fflags = q->flush_flags; /* may change, cache it */ bool has_flush = fflags & REQ_FLUSH, has_fua = fflags & REQ_FUA; bool do_preflush = has_flush && (rq->cmd_flags & REQ_FLUSH); bool do_postflush = has_flush && !has_fua && (rq->cmd_flags & REQ_FUA); unsigned skip = 0; ... if (blk_rq_sectors(rq) && !do_preflush && !do_postflush) { rq->cmd_flags &= ~REQ_FLUSH; if (!has_fua) rq->cmd_flags &= ~REQ_FUA; return rq; } So, the flush machinery was bypassed in such cases (q->flush_flags == 0 && rq->cmd_flags & (REQ_FLUSH|REQ_FUA)). Now, however, we don't get into the flush machinery at all. Instead, __elv_next_request just hands a request with flush and fua bits set to the scsi_request_fn, even if the underlying request_queue does not support flush or fua. The agreed upon approach is to fix the flush machinery to allow stacking. While this isn't used in practice (since there is only one request-based dm target, and that target will now reflect the flush flags of the underlying device), it does future-proof the solution, and make it function as designed. In order to make this work, I had to add a field to the struct request, inside the flush structure (to store the original req->end_io). Shaohua had suggested overloading the union with rb_node and completion_data, but the completion data is used by device mapper and can also be used by other drivers. So, I didn't see a way around the additional field. I tested this patch on an HP EVA with both ext4 and xfs, and it recovers the lost performance. Comments and other testers, as always, are appreciated. Cheers, Jeff Signed-off-by: Jeff Moyer <jmoyer@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-15drm/i915: Cannot set clock gating under UMSKeith Packard1-1/+2
The clock gating functions are only assigned under KMS, so don't try to call them under UMS. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Justin P. Mattock <justinmattock@gmail.com>
2011-08-15drm/i915: Can't do accurate vblank timestamps with UMSKeith Packard1-2/+4
Disable this feature when KMS is not running by setting the driver->get_vblank_timestamp function pointer to NULL. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Justin P. Mattock <justinmattock@gmail.com>
2011-08-15Not all systems expose a firmware or platform mechanism for changing the ↵Matthew Garrett6-3/+89
backlight intensity on i915, so add native driver support. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> Tested-by: Michel Alexandre Salim <salimma@fedoraproject.org> Tested-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Keith Packard <keithp@keithp.com>
2011-08-15drm/radeon/kms: don't try to be smart in the hpd handlerAlex Deucher3-8/+19
Attempting to try and turn off disconnected display hw in the hotput handler lead to more problems than it helped. For now just register an event and only attempt the do something interesting with DP. Other connectors are just too problematic: - Some systems have an HPD pin assigned to LVDS, but it's rarely if ever connected properly and we don't really care about hpd events on LVDS anyway since it's always connected. - The HPD pin is wired up correctly for eDP, but we don't really have to do anything since the events since it's always connected. - Some HPD pins fire more than once when you connect/disconnect - etc. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39882 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-08-15lguest: allow booting guest with CONFIG_RELOCATABLE=yRusty Russell1-0/+3
The CONFIG_RELOCATABLE code tries to align the unpack destination to the value of 'kernel_alignment' in the setup_hdr. If that's 0, it tries to unpack to address 0, which in fact causes the gunzip code to call 'error("Out of memory while allocating output buffer")'. The bootloader (ie. the lguest Launcher in this case) should be doing setting this field; the normal bzImage is 16M, we can use the same. Reported-by: Stefanos Geraggelos <sgerag@cslab.ece.ntua.gr> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org
2011-08-15virtio: Add text copy of spec to Documentation/virtual.Rusty Russell2-0/+2203
As suggested by Christoph Hellwig. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>