On 10/25/12 7:12 PM, Ilija Hadzic wrote: > On Thu, Oct 25, 2012 at 11:10 AM, Thomas Hellstr?m > <thellstrom at vmware.com> wrote: >> On 10/25/12 4:41 PM, Jerome Glisse wrote: >>> On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote: >>>> Hi, >>>> >>>> This commit >>>> >>>> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001 >>>> From: Ilija Hadzic <ihadzic at research.bell-labs.com> >>>> Date: Tue, 15 May 2012 16:40:10 -0400 >>>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way >>>> >>>> Setting dev_mapping (pointer to the address_space structure >>>> used for memory mappings) to the address_space of the first >>>> opener's inode and then failing if other openers come in >>>> through a different inode has a few restrictions that are >>>> eliminated by this patch. >>>> >>>> If we already have valid dev_mapping and we spot an opener >>>> with different i_node, we force its i_mapping pointer to the >>>> already established address_space structure (first opener's >>>> inode). This will make all mappings from drm device hang off >>>> the same address_space object. >>>> ... >>>> >>>> Breaks drivers using TTM, since when the X server calls into the >>>> driver open, drm's dev_mapping has not >>>> yet been setup. The setup needs to be moved before the driver's open >>>> hook is called. >>>> >>>> Typically, if a TTM-aware driver is provoked by the Xorg server to >>>> move a buffer from system to VRAM or AGP, >>>> before any other drm client is started, The user-space page table >>>> entries are not killed before the move, and left pointing >>>> into freed pages, causing system crashes and / or user-space access >>>> to arbitrary memory. >>> Doesn't handle move invalidate the drm file mapping before scheduling >>> the move ? >> Yes, but to do that it needs a correct value of bdev::dev_mapping, which is >> now incorrectly set on the >> *second* open instead of the first open. >> > So you are implying that in the first open the assignment of dev->dev_mapping > is > somehow skipped (which could happen if drm_setup returns an error) or that the > driver on which you are having problems with (nouveau I presume) needs > dev_mapping > in the firstopen hook ? No. On open, driver::open is called from drm::open. It copies the value of dev->dev_mapping, however, driver::open is called *before* dev->dev_mapping is set up, so what I'm saying is that the setup of dev->dev_mapping must be moved to before driver::open is called from drm::open
(this was hit while testing vmwgfx with new code, BTW. It will be hard, but probably possible to trigger from unpriviliged user-space with the current vmwgfx code. Thanks, Thomas
