- 11 2月, 2010 11 次提交
-
-
由 Luca Barbieri 提交于
This patch introduces the drm_gem_object_unreference_unlocked and drm_gem_object_handle_unreference_unlocked functions that do not require holding struct_mutex. drm_gem_object_unreference_unlocked calls the new ->gem_free_object_unlocked entry point if available, and otherwise just takes struct_mutex and just calls ->gem_free_object Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Andy Getzendanner 提交于
This patch corrects a userspace pointer dereference in the VGA arbiter in 2.6.32.1. copy_from_user() is used at line 822 to copy the contents of buf into kbuf, but a call to strncmp() on line 964 uses buf rather than kbuf. This problem led to a GPF in strncmp() when X was started on my x86_32 systems. X triggered the behavior with a write of "target PCI:0000:01:00.0" to /dev/vga_arbiter. The patch has been tested against 2.6.32.1 and observed to correct the GPF observed when starting X or manually writing the string "target PCI:0000:01:00.0" to /dev/vga_arbiter. Signed-off-by: NAndy Getzendanner <james.getzendanner@students.olin.edu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
ATOM appears to return 0x20 which seems to mean some sort of timeout. retry the transaction up to 10 times before failing, this makes DP->VGA convertor we bought work at least a bit more predictably. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Pauli Nieminen 提交于
radeon_copy_dma is only available for r200 or newer cards. Call to radeon_copy_dma would result to NULL pointer dereference if benchmarking asic without dma engine. Signed-off-by: NPauli Nieminen <suokkos@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Even if this bumps the version to 1 it does not mean the driver is out of staging. From what we know this is the last backwards incompatible change to the driver. Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jakob Bornecrantz 提交于
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
When time-based throttling is implemented, we need to bump minor. When the old way of detecting scanout is removed, we need to bump major. In the meantime, this change should not break existing user-space. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NJakob Bornecrantz <jakob@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This memset_io was added to debug something way back and got left behind, memset the fb to black so the borders don't be all white. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Matthew Garrett 提交于
Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Reported-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 10 2月, 2010 7 次提交
-
-
由 NeilBrown 提交于
====== This fix is related to http://bugzilla.kernel.org/show_bug.cgi?id=15142 but does not address that exact issue. ====== sysfs does like attributes being removed while they are being accessed (i.e. read or written) and waits for the access to complete. As accessing some md attributes takes the same lock that is held while removing those attributes a deadlock can occur. This patch addresses 3 issues in md that could lead to this deadlock. Two relate to calling flush_scheduled_work while the lock is held. This is probably a bad idea in general and as we use schedule_work to delete various sysfs objects it is particularly bad. In one case flush_scheduled_work is called from md_alloc (called by md_probe) called from do_md_run which holds the lock. This call is only present to ensure that ->gendisk is set. However we can be sure that gendisk is always set (though possibly we couldn't when that code was originally written. This is because do_md_run is called in three different contexts: 1/ from md_ioctl. This requires that md_open has succeeded, and it fails if ->gendisk is not set. 2/ from writing a sysfs attribute. This can only happen if the mddev has been registered in sysfs which happens in md_alloc after ->gendisk has been set. 3/ from autorun_array which is only called by autorun_devices, which checks for ->gendisk to be set before calling autorun_array. So the call to md_probe in do_md_run can be removed, and the check on ->gendisk can also go. In the other case flush_scheduled_work is being called in do_md_stop, purportedly to wait for all md_delayed_delete calls (which delete the component rdevs) to complete. However there really isn't any need to wait for them - they have already been disconnected in all important ways. The third issue is that raid5->stop() removes some attribute names while the lock is held. There is already some infrastructure in place to delay attribute removal until after the lock is released (using schedule_work). So extend that infrastructure to remove the raid5_attrs_group. This does not address all lockdep issues related to the sysfs "s_active" lock. The rest can be address by splitting that lockdep context between symlinks and non-symlinks which hopefully will happen. Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Maarten Maathuis 提交于
Unset the bit that indicates that a ctxprog can continue at the end. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
ramfc is zero'ed upon destruction, so it's safer to do things in the right order. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
- We need to disable pgraph fifo access before checking the current channel, otherwise we could still hit a running ctxprog. - The writes to 0x400500 are already handled by pgraph->fifo_access and are therefore redundant, moreover pgraph fifo access should not be reenabled before current context is set as invalid. So remove them altogether. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Maarten Maathuis 提交于
- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes DVI+VGA on my 9400, and likely a lot of other configurations that got broken by the previos DVI-over-DP fix. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
With DVI and DP plugged, the DVI clock change interrupts being run can cause DP link training to fail. This adds a spinlock around init table parsing to prevent this. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 09 2月, 2010 17 次提交
-
-
由 Jan Glauber 提交于
If a CHPID is offline during a device shutdown the ccw_device_halt|clear may fail and the qdio device stays in state STOPPED until the shutdown is finished. If an interrupt occurs before the device is set to INACTIVE the STOPPED state triggers a WARN_ON in the interrupt handler. Prevent this WARN_ON by catching the STOPPED state in the interrupt handler. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Ursula Braun 提交于
Inbound traffic handling may hang if next buffer to check is in state ERROR, polling is stopped and the final check for further available inbound buffers disregards buffers in state ERROR. This patch includes state ERROR when checking availability of more inbound buffers. Cc: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Julia Lawall 提交于
Test the value that was just allocated rather than the previously tested one. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ expression *x; expression e; identifier l; @@ if (x == NULL || ...) { ... when forall return ...; } ... when != goto l; when != x = e when != &x *x == NULL // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Divy Le Ray 提交于
Verify the HW checksum state for frames handed to GRO processing. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 NeilBrown 提交于
This code was written long ago when it was not possible to reshape a degraded array. Now it is so the current level of degraded-ness needs to be taken in to account. Also newly addded devices should only reduce degradedness if they are deemed to be in-sync. In particular, if you convert a RAID5 to a RAID6, and increase the number of devices at the same time, then the 5->6 conversion will make the array degraded so the current code will produce a wrong value for 'degraded' - "-1" to be precise. If the reshape runs to completion end_reshape will calculate a correct new value for 'degraded', but if a device fails during the reshape an incorrect decision might be made based on the incorrect value of "degraded". This patch is suitable for 2.6.32-stable and if they are still open, 2.6.31-stable and 2.6.30-stable as well. Cc: stable@kernel.org Reported-by: NMichael Evans <mjevans1983@gmail.com> Signed-off-by: NNeilBrown <neilb@suse.de>
-
由 Ben Skeggs 提交于
Writes don't return a count, and adding the check broke native DP. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
It appears we aren't required to do memory sizing ourselves on nv40 either. NV40 init tables read a strap from PEXTDEV_BOOT_0 into a CRTC register, and then later use that value to select a memory configuration (written to PFB_CFG0, just like INIT_COMPUTE_MEM on earlier cards) with INIT_IO_RESTRICT_PROG. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Kościelnicki 提交于
Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Kościelnicki 提交于
We used single shared fbops struct and patched it at fb init time with pointers to the right variant. On mixed multicard, this meant that it was either sending NV50-style commands to all cards, or NV04-style commands to all cards. Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Julia Lawall 提交于
Test the just-allocated value for NULL rather than some other value. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,y; statement S; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ( if ((x) == NULL) S | if ( - y + x == NULL) S ) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Luca Barbieri 提交于
nouveau_gem_ioctl_cpu_prep calls ttm_bo_wait without the bo lock held. ttm_bo_wait unlocks that lock, and so must be called with it held. Currently this bug causes libdrm nouveau_bo_busy() to hang the machine. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> Acked-by: NMaarten Maathuis <madman2003@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Apparently, they generate a PFIFO interrupt each time one of the semaphore methods is executed if its ctxdma wasn't manually marked as valid. This patch makes it flip the valid bit in response to the DMA_SEMAPHORE method (which triggers the IRQ even for a valid ctxdma). Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Kościelnicki 提交于
On nv50, this will be needed by applications using CUDA to know how much stack/local memory to allocate. Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Kościelnicki 提交于
noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Due to a thinko, these were previously forced to VRAM even if we allocated them in GART. This commit fixes that bug, but keeps the previous behaviour of using VRAM by default until it's been tested properly across more chipsets. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Dave Airlie 提交于
Reported on irc by nirbheek. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This is strange - like really really strange, twilight zone of strange. VGA ports have DDC buses, but sometimes for some reasons the BIOS says we don't and we oops - AMD mentioned bios bugs so we'll have to add quirks. reported on irc by nirbheek and https://bugzilla.redhat.com/show_bug.cgi?id=554323Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 08 2月, 2010 5 次提交
-
-
由 Francesco Lavra 提交于
A DVB demultiplexer device can be used to set up either a PES filter or a section filter. In the former case, the ts field of the feed union of struct dmxdev_filter is used, in the latter case the sec field of the same union is used. The ts field is a struct list_head, and is currently initialized in the open() method of the demux device. When for a given demuxer a section filter is set up, the sec field is played with, thus if a PES filter needs to be set up after that the ts field will be corrupted, causing a kernel oops. This fix moves the list head initialization to dvb_dmxdev_pes_filter_set(), so that the ts field is properly initialized every time a PES filter is set up. Signed-off-by: NFrancesco Lavra <francescolavra@interfree.it> Cc: stable <stable@kernel.org> Reviewed-by: NAndy Walls <awalls@radix.net> Tested-by: Nhermann pitton <hermann-pitton@arcor.de> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
As dvb_dmx_swfilter_packet() is protected by a spinlock, it shouldn't sleep. However, vmalloc() may call sleep. So, move the initialization of dvb_demux::cnt_storage field to a better place. Reviewed-by: NAndy Walls <awalls@radix.net> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
dvb_dmx_init tries to allocate virtual memory for 2 pointers: filter and feed. If the second vmalloc fails, filter is freed, but the pointer keeps pointing to the old place. Later, when dvb_dmx_release() is called, it will try to free an already freed memory, causing an OOPS. Reviewed-by: NAndy Walls <awalls@radix.net> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Dave Airlie 提交于
Ingo pointed out that we really don't give the user enough warning to make a decision here. So revise the Kconfig text with a better warning. Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Linus Torvalds 提交于
This reverts commit 70362511 ("tty: fix race in tty_fasync") and commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/ restore") that tried to fix up some of the fallout but was incomplete. It turns out that we really cannot hold 'tty->ctrl_lock' over calling __f_setown, because not only did that cause problems with interrupt disables (which the second commit fixed), it also causes a potential ABBA deadlock due to lock ordering. Thanks to Tetsuo Handa for following up on the issue, and running lockdep to show the problem. It goes roughly like this: - f_getown gets filp->f_owner.lock for reading without interrupts disabled, so an interrupt that happens while that lock is held can cause a lockdep chain from f_owner.lock -> sighand->siglock. - at the same time, the tty->ctrl_lock -> f_owner.lock chain that commit 70362511 introduced, together with the pre-existing sighand->siglock -> tty->ctrl_lock chain means that we have a lock dependency the other way too. So instead of extending tty->ctrl_lock over the whole __f_setown() call, we now just take a reference to the 'pid' structure while holding the lock, and then release it after having done the __f_setown. That still guarantees that 'struct pid' won't go away from under us, which is all we really ever needed. Reported-and-tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Acked-by: NAmérico Wang <xiyou.wangcong@gmail.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-