- 26 Apr, 2010 14 commits
-
-
Christoph Hellwig authored
commit b44b1126 upstream Add an assert for inodes not added to the inode cache in xfs_ireclaim, to make sure we're not going to introduce something like the famous nfsd inode cache bug again. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Alex Elder <aelder@sgi.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jason Gunthorpe authored
commit 44a743f6 upstream Noticed that through glibc fallocate would return 28 rather than -1 and errno = 28 for ENOSPC. The xfs routines uses XFS_ERROR format positive return error codes while the syscalls use negative return codes. Fixup the two cases in xfs_vn_fallocate syscall to convert to negative. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by:
Eric Sandeen <sandeen@sandeen.net> Signed-off-by:
-
Andy Poling authored
commit fc5bc4c8 upstream Summary of problem: If a journal record wraps at the physical end of the journal, it has to be read in two parts in xlog_do_recovery_pass(): a read at the physical end and a read at the physical beginning. If xlog_bread() has to re-align the first read, the second read request does not take that re-alignment into account. If the first read was re-aligned, the second read over-writes the end of the data from the first read, effectively corrupting it. This can happen either when reading the record header or reading the record data. The first sanity check in xlog_recover_process_data() is to check for a valid clientid, so that is the error reported. Summary of fix: If there was a first read at the physical end, XFS_BUF_PTR() returns where the data was requested to begin. Conversely, because it is the result of xlog_align(), offset indicates where the requested data for the first read actually begins - whether or not xlog_bread() has re-aligned it. Using offset as the base for the calculation of where to place the second read data ensures that it will be correctly placed immediately following the data from the first read instead of sometimes over-writing the end of it. The attached patch has resolved the reported problem of occasional inability to recover the journal (reporting "bad clientid"). Signed-off-by:
Andy Poling <andy@realbig.com> Reviewed-by:
-
Christoph Hellwig authored
commit 80641dc6 upstream When completing I/O requests we must not allow the memory allocator to recurse into the filesystem, as we might deadlock on waiting for the I/O completion otherwise. The only thing currently allocating normal GFP_KERNEL memory is the allocation of the transaction structure for the unwritten extent conversion. Add a memflags argument to _xfs_trans_alloc to allow controlling the allocator behaviour. Signed-off-by:
Thomas Neumann <tneumann@users.sourceforge.net> Tested-by:
-
Christoph Hellwig authored
commit c56c9631 upstream When xfs_free_eofblocks is called from ->release the VM might already hold the mmap_sem, but in the write path we take the iolock before taking the mmap_sem in the generic write code. Switch xfs_free_eofblocks to only trylock the iolock if called from ->release and skip trimming the prellocated blocks in that case. We'll still free them later on the final iput. Signed-off-by:
-
Christoph Hellwig authored
commit 848ce8f7 upstream Currently the reclaim code for the case where we don't reclaim the final reclaim is overly complicated. We know that the inode is clean but instead of just directly reclaiming the clean inode we go through the whole process of marking the inode reclaimable just to directly reclaim it from the calling context. Besides being overly complicated this introduces a race where iget could recycle an inode between marked reclaimable and actually being reclaimed leading to panics. This patch gets rid of the existing reclaim path, and replaces it with a simple call to xfs_ireclaim if the inode was clean. While we're at it we also use the slightly more lax xfs_inode_clean check we'd use later to determine if we need to flush the inode here. Finally get rid of xfs_reclaim function and place the remaining small bits of reclaim code directly into xfs_fs_destroy_inode. Signed-off-by:
Patrick Schreurs <patrick@news-service.com> Reported-by:
Tommy van Leeuwen <tommy@news-service.com> Tested-by:
-
Chris Wilson authored
commit da584058 upstream. Replace a BUG_ON with an error code in the event that the inode mapping changes between calls to drm_open. This may happen for instance if udev is loaded subsequent to the original opening of the device: [ 644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146! [ 644.291876] invalid opcode: 0000 [#1] SMP [ 644.291882] last sysfs file: /sys/kernel/uevent_seqnum [ 644.291888] [ 644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2 N150/N210/N220 /N150/N210/N220 [ 644.291903] EIP: 0060:[<c11c70e3>] EFLAGS: 00210283 CPU: 0 [ 644.291912] EIP is at drm_open+0x4b1/0x4e2 [ 644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX: 00000000 [ 644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc [ 644.291929] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80 task.ti=f647a000) [ 644.291941] Stack: [ 644.291945] 00000000 f7bb7400 00000080 f6451100 f73176b8 f6479214 f6451100 f73176b8 [ 644.291957] <0> c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800 00000000 f647ae54 c1080ac5 [ 644.291969] <0> f7949800 f6451100 00000000 f6451100 f73176b8 f6452780 f647ae70 c107d1e6 [ 644.291982] Call Trace: [ 644.291991] [<c11c6c04>] ? drm_stub_open+0x8a/0xb8 [ 644.292000] [<c1080ac5>] ? chrdev_open+0xef/0x106 [ 644.292008] [<c107d1e6>] ? __dentry_open+0xd4/0x1a6 [ 644.292015] [<c107d35b>] ? nameidata_to_filp+0x31/0x45 [ 644.292022] [<c10809d6>] ? chrdev_open+0x0/0x106 [ 644.292030] [<c10864e2>] ? do_last+0x346/0x423 [ 644.292037] [<c108789f>] ? do_filp_open+0x190/0x415 [ 644.292046] [<c1071eb5>] ? handle_mm_fault+0x214/0x710 [ 644.292053] [<c107d008>] ? do_sys_open+0x4d/0xe9 [ 644.292061] [<c1016462>] ? do_page_fault+0x211/0x23f [ 644.292068] [<c107d0f0>] ? sys_open+0x23/0x2b [ 644.292075] [<c1002650>] ? sysenter_do_call+0x12/0x26 [ 644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04 01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 <0f> 0b eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0 [ 644.292143] EIP: [<c11c70e3>] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc [ 644.292175] ---[ end trace 2ddd476af89a60fa ]--- Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 15f72077 upstream. Based on ddx patch by Andrzej Hajda. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Dave Airlie authored
commit 97f23b3d upstream. We can get this if the user moves the mouse when we are waiting to move some stuff around in the validate. Don't fail. Signed-off-by:
-
Oleg Nesterov authored
commit b95c35e7 upstream. proc_oom_score(task) has a reference to task_struct, but that is all. If this task was already released before we take tasklist_lock - we can't use task->group_leader, it points to nowhere - it is not safe to call badness() even if this task is ->group_leader, has_intersects_mems_allowed() assumes it is safe to iterate over ->thread_group list. - even worse, badness() can hit ->signal == NULL Add the pid_alive() check to ensure __unhash_process() was not called. Also, use "task" instead of task->group_leader. badness() should return the same result for any sub-thread. Currently this is not true, but this should be changed anyway. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Nikolaus Schulz authored
commit 30d1872d upstream. When using the string representation of a random counter as part of the base name, ensure that it is no longer than 4 bytes. Since we are repeatedly decrementing the counter in a loop until we have found a unique base name, the counter may wrap around zero; therefore, it is not enough to mask its higher bits before entering the loop, this must be done inside the loop. [hirofumi@mail.parknet.co.jp: use snprintf()] Signed-off-by:
Nikolaus Schulz <microschulz@web.de> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Zhao Yakui authored
commit 72539832 upstream. Now the EDID property will be updated when the corresponding EDID can be obtained from the external display device. But after the external device is plugged-out, the EDID property is not updated. In such case we still get the corresponding EDID property although it is already detected as disconnected. https://bugs.freedesktop.org/show_bug.cgi?id=26743Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Alex Deucher authored
commit 338e2b1d upstream. This should go to 2.6.33 stable as well. Signed-off-by:
-
Ben Skeggs authored
commit 44fef224 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 01 Apr, 2010 26 commits
-
-
Greg Kroah-Hartman authored
-
Sachin Prabhu authored
commit 720e7749 upstream. gfs2_lock() will skip locks on file which have mode set to 02666. This is a problem in cases where the mode of the file is changed after a process has obtained a lock on the file. Such a lock will be skipped and will result in a BUG in locks_remove_flock(). gfs2_lock() should skip the check for mandatory locks when unlocking a file. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Dimitri Sivanich authored
commit 14be1f74 upstream. On UV systems, the TSC is not synchronized across blades. The sched_clock_cpu() function is returning values that can go backwards (I've seen as much as 8 seconds) when switching between cpus. As each cpu comes up, early_init_intel() will currently set the sched_clock_stable flag true. When mark_tsc_unstable() runs, it clears the flag, but this only occurs once (the first time a cpu comes up whose TSC is not synchronized with cpu 0). After this, early_init_intel() will set the flag again as the next cpu comes up. Only set sched_clock_stable if tsc has not been marked unstable. Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Acked-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <20100301174815.GC8224@sgi.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Lars-Peter Clausen authored
commit c212808a upstream. If no platform_data was givin to the device it's going to use it's default platform data struct which has all fields initialized to zero. As a result the driver is going to try to request gpio0 both as write protect and card detect pin. Which of course will fail and makes the driver unusable Previously to the introduction of no_wprotect and no_detect the behavior was to assume that if no platform data was given there is no write protect or card detect pin. This patch restores that behavior. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: Ben Dooks <ben-linux@fluff.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Martin K. Petersen authored
block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34 The stacking code incorrectly scaled up the data offset in some cases causing misaligned devices to report alignment. Rewrite the stacking algorithm to remedy this. (Upstream commit 9504e086) The top device misalignment flag would not be set if the added bottom device was already misaligned as opposed to causing a stacking failure. Also massage the reporting so that an error is only returned if adding the bottom device caused the misalignment. I.e. don't return an error if the top is already flagged as misaligned. (Upstream commit fe0b393f) lcm() was defined to take integer-sized arguments. The supplied arguments are multiplied, however, causing us to overflow given sufficiently large input. That in turn led to incorrect optimal I/O size reporting in some cases. Switch lcm() over to unsigned long similar to gcd() and move the function from blk-settings.c to lib. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Michael Buesch authored
commit 96869a39 upstream The TKIP key update callback is called from the RX path, where the driver mutex is already locked. This results in a circular locking bug. Avoid this by removing the lock. Johannes noted that there is a separate bug: The callback still breaks on SDIO hardware, because SDIO hardware access needs to sleep, but we are not allowed to sleep in the callback due to mac80211's RCU locking. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by: kecsa@kutfo.hit.bme.hu Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
commit 319c2cc7 upstream. Signed-off-by:
Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com> Signed-off-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Andrei Emeltchenko authored
commit c2c77ec8 upstream. Added very simple check that req buffer has enough space to fit configuration parameters. Shall be enough to reject packets with configuration size more than req buffer. Crash trace below [ 6069.659393] Unable to handle kernel paging request at virtual address 02000205 [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT ... [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap] [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap] ... [ 6070.030303] Backtrace: [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap]) [ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200 [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap]) [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth]) [ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740 [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from [<c006b9fc>] (tasklet_action+0x78/0xd8) [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>] Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by:
Gustavo F. Padovan <gustavo@padovan.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Marcel Holtmann authored
commit 101545f6 upstream. When creating a high number of Bluetooth sockets (L2CAP, SCO and RFCOMM) it is possible to scribble repeatedly on arbitrary pages of memory. Ensure that the content of these sysfs files is always less than one page. Even if this means truncating. The files in question are scheduled to be moved over to debugfs in the future anyway. Based on initial patches from Neil Brown and Linus Torvalds Reported-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Tejun Heo authored
commit 9deb3431 upstream. HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making ahci_broken_suspend() trigger for later products which are not affected by the original problems. Match BIOS date instead of version and add references to bko's so that full information can be found easier later. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by: tigerfishdaisy@gmail.com Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jan Kara authored
commit 0a5a9c72 upstream. If a delayed-allocation write happens before quota is enabled, the kernel spits out a warning: WARNING: at fs/quota/dquot.c:988 dquot_claim_space+0x77/0x112() because the fact that user has some delayed allocation is not recorded in quota structure. Make dquot_initialize() update amount of reserved space for user if it sees inode has some space reserved. Also make sure that reserved quota space does not go negative and we warn about the filesystem bug just once. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dmitry Monakhov authored
commit c469070a upstream. Since we implemented generic reserved space management interface, then it is possible to account reserved space even when quota is not active (similar to i_blocks/i_bytes). Without this patch following testcase result in massive comlain from WARN_ON in dquot_claim_space() TEST_CASE: mount /dev/sdb /mnt -oquota dd if=/dev/zero of=/mnt/test bs=1M count=1 quotaon /mnt # fs_reserved_spave == 1Mb # quota_reserved_space == 0, because quota was disabled dd if=/dev/zero of=/mnt/test seek=1 bs=1M count=1 # fs_reserved_spave == 2Mb # quota_reserved_space == 1Mb sync # ->dquot_claim_space() -> WARN_ON Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Anton Vorontsov authored
commit 0493a4ff upstream. The driver wrongly sets default state for LEDs that don't specify default-state property. Currently the driver handles default state this way: memset(&led, 0, sizeof(led)); for_each_child_of_node(np, child) { state = of_get_property(child, "default-state", NULL); if (state) { if (!strcmp(state, "keep")) led.default_state = LEDS_GPIO_DEFSTATE_KEEP; ... } ret = create_gpio_led(&led, ...); } Which means that all LEDs that do not specify default-state will inherit the last value of the default-state property, which is wrong. This patch fixes the issue by moving LED's template initialization into the loop body. Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
-
Vivek Natarajan authored
commit e15276a4 upstream. The current mac80211 implementation enables power save if there is no Tx traffic for a specific timeout. Hence, PS is triggered even if there is a continuous Rx only traffic(like UDP) going on. This makes the drivers to wait on the tim bit in the next beacon to awake which leads to redundant sleep-wake cycles. Fix this by restarting the dynamic ps timer on receiving every data packet. Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Vivek Natarajan authored
commit 05df4986 upstream. Signed-off-by:
-
Vivek Natarajan authored
commit 375177bf upstream. Even if the null data frame is not acked by the AP, mac80211 goes into power save. This might lead to loss of frames from the AP. Prevent this by restarting dynamic_ps_timer when ack is not received for null data frames. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Senthil Balasubramanian authored
commit 3f7c5c10 upstream. The TIM timer interrupt is enabled even before the ACK of nullqos is received which is unnecessary. Also clean up the CONF_PS part of config callback properly for better readability. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Daniel T Chen authored
commit 950200e2 upstream. BugLink: https://bugs.launchpad.net/bugs/418627 The original reporter states that this quirk is necessary to obtain reasonable gain for playback. Without it, sound is inaudible. Tested with playback (spkr and hp) and capture. Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel T Chen authored
commit e1f7f02b upstream. BugLink: https://launchpad.net/bugs/303789 This model needs both 'Headphone Jack Sense' and 'Line Jack Sense' muted for audible audio, so just add its SSID to the blacklist and don't enumerate the controls. Signed-off-by:
-
Daniel Chen authored
commit 5cd165e7 upstream. BugLink: https://launchpad.net/bugs/481058 The OR has verified that both 'Headphone Jack Sense' and 'Line Jack Sense' need to be muted for sound to be audible, so just add the machine's SSID to the ac97 jack sense blacklist. Reported-by: Richard Gagne Tested-by: Richard Gagne Signed-off-by:
-
Daniel T Chen authored
commit 9ec8ddad upstream. BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575669 The OR states that position_fix=1 is necessary to work around glitching during volume adjustments using PulseAudio. Reported-by:
Carlos Laviola <claviola@debian.org> Tested-by:
-
Dean Nelson authored
commit 4d7a5644 upstream. Add missing newline to dev_warn() message string. This is more of an issue with older kernels that don't automatically add a newline if it was missing from the end of the previous line. Signed-off-by:
Dean Nelson <dnelson@redhat.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Andreas Herrmann authored
commit 035a02c1 upstream. Currently c1e_idle returns true for all CPUs greater than or equal to family 0xf model 0x40. This covers too many CPUs. Meanwhile a respective erratum for the underlying problem was filed (#400). This patch adds the logic to check whether erratum #400 applies to a given CPU. Especially for CPUs where SMI/HW triggered C1e is not supported, c1e_idle() doesn't need to be used. We can check this by looking at the respective OSVW bit for erratum #400. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100319110922.GA19614@alberich.amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Jan Beulich authored
commit ff30a054 upstream. Ever for 32-bit with sufficiently high NR_CPUS, and starting with commit 789d03f5 also for 64-bit, the statically allocated early fixmap page tables were not covering FIX_OHCI1394_BASE, leading to a boot time crash when "ohci1394_dma=early" was used. Despite this entry not being a permanently used one, it needs to be moved into the permanent range since it has to be close to FIX_DBGP_BASE and FIX_EARLYCON_MEM_BASE. Reported-bisected-and-tested-by:
Justin P. Mattock <justinmattock@gmail.com> Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=14487Signed-off-by:
Jan Beulich <jbeulich@novell.com> LKML-Reference: <4B9E15D30200007800034D23@vpn.id2.novell.com> Signed-off-by:
-
Patrick McHardy authored
commit ef169150 upstream. Commit 8ccb92ad (netfilter: xt_recent: fix false match) fixed supposedly false matches in rules using a zero hit_count. As it turns out there is nothing false about these matches and people are actually using entries with a hit_count of zero to make rules dependant on addresses inserted manually through /proc. Since this slipped past the eyes of three reviewers, instead of reverting the commit in question, this patch explicitly checks for a hit_count of zero to make the intentions more clear. Reported-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Chris Wilson authored
commit 1f2b1013 upstream. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15527 NULL pointer dereference in i915_gem_object_save_bit_17_swizzle BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f82b5d2b>] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915] Call Trace: [<f82aea55>] ? i915_gem_object_put_pages+0x125/0x150 [i915] [<f82aeb71>] ? i915_gem_object_get_pages+0xf1/0x110 [i915] [<f82b0de8>] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915] [<c02db74d>] ? drm_mm_get_block_generic+0x4d/0x180 [<f82b11cd>] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915] [<f82ae786>] ? i915_gem_madvise_ioctl+0x86/0x120 [i915] Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
