1) It is not useful to call "devfs_clear_cdevpriv()" from
"d_close" callbacks, hence for example read, write, ioctl and
so on might be sleeping at the time of "d_close" being called
and then then freed private data can still be accessed.
Examples: dtrace, linux_compat, ksyms (all fixed by this patch)
2) In sys/dev/drm* there are some cases in which memory will
be freed twice, if open fails, first by code in the open
routine, secondly by the cdevpriv destructor. Move registration
of the cdevpriv to the end of the drm open routines.
3) devfs_clear_cdevpriv() is not called if the "d_open" callback
registered cdevpriv data and the "d_open" callback function
returned an error. Fix this.
Discussed with: phk
MFC after: 2 weeks
unsupported form of the latter. This change has been reviewed and accepted
in the -hackers list.
Submitted by: Alexander Best
Reviewed by: David Schulz
scope of the object lock in agp_i810.c. (In this specific case, the scope
of the object lock shouldn't matter, but I don't want to create a bad
example that might be copied to a case where it did matter.)
Reviewed by: kib
architecture from page queue lock to a hashed array of page locks
(based on a patch by Jeff Roberson), I've implemented page lock
support in the MI code and have only moved vm_page's hold_count
out from under page queue mutex to page lock. This changes
pmap_extract_and_hold on all pmaps.
Supported by: Bitgravity Inc.
Discussed with: alc, jeffr, and kib
Some of these cases should be safe in a non-atomic fashion, however
since all of the driver ioctls are locked, a lot of work is required to
fix it correctly. Just don't sleep now.
MFC after: 2 weeks
This time, abandon the use of busdma and start interacting with the VM
system directly. Make use of the new kmem_alloc_attr() which allows us
to easily allocate non-contiguous pages to back the GART table. This
should help a lot when starting or restarting X after the system has
been running for a while and memory has become fragmented.
MFC after: 2 weeks
* On 32 bit platforms we steal the upper 4 bits of the map handle
to store a unique map id.
* On 64 bit platforms we steal the upper 24 bits.
Resolves issues where the offsets that are handed to mmap may overlap the VRAM on some cards.
Tested on: radeon, intel, mga, and via.
This will break nouveau. I will spin new patches shortly.
This replaces d_mmap() with the d_mmap2() implementation and also
changes the type of offset to vm_ooffset_t.
Purge d_mmap2().
All driver modules will need to be rebuilt since D_VERSION is also
bumped.
Reviewed by: jhb@
MFC after: Not in this lifetime...
- Don't bother to assign vb until we know we have enough space
- Add variables for sx2, sy2, dx2, dy2 so that these aren't
calculated over and over, also reduce chance of errors.
- Use switch to assign color/format
MFC after: 3 days
- We don't need to check malloc return values with M_WAITOK
- remove variables that we don't really need
- cleanup the error paths by just calling drm_sg_cleanup()
- fix drm_sg_cleanup() to be safe to call at any time
MFC after: 2 weeks
