From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind Sankar Subject: questions about fb_pan_display ioctl Date: Sat, 30 Aug 2003 13:02:47 -0400 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <20030830170247.GA17072@scrubbing-bubbles.mit.edu> Mime-Version: 1.0 Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 19t97j-0007W4-00 for ; Sat, 30 Aug 2003 10:02:51 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 19t97i-0001jD-T3 for linux-fbdev-devel@lists.sourceforge.net; Sat, 30 Aug 2003 10:02:50 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h7UH2me9009041 for ; Sat, 30 Aug 2003 13:02:48 -0400 (EDT) Content-Disposition: inline Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-fbdev-devel@lists.sourceforge.net Cc: arvinds@MIT.EDU I was looking through the source, and am mightily confused as to how this works. 1. The FBIOPAN_DISPLAY ioctl does not error-check var. 2. fb_pan_display uses info->var to bounds-check var->?offset. 3. fb_pan_display modifies info->var, but var is what is returned by the ioctl. 4. The function pointer info->fbops->fb_pan_display takes its args in the opposite order to fb_pan_display! Who came up with this? 5. vesafb_pan_display uses var to bounds-check var->?offset, which is (a) pointless, since fb_pan_display has bounds-checked it already. (b) buggy, since var has never been error-checked, so var->yres could be anything. 6. How does wrapping work, when fb_pan_display has already made sure that yoffset cannot cause display to go beyond yres_virtual? The checks in vesafb_pan_display do this only when ywrap is disabled, but fb_pan_display always does it. 7. vesafb never uses more than 16mb of video ram, so wrapping can _never_ happen on boards with more than 16mb of ram, no? All these comments refer to 2.6.0-test4. Point 6 should apply to all the fb devices, not just vesafb. In 2.4.22, there is no fb_pan_display, but vesafb_pan_display is the same, so it turns out that wrapping is allowed, but subject to the issues in 5(b) and 7. The issue in 7 is actually worse, because unless the vram option is passed, the video size is computed from the mode resolution, so it has nothing to do with the actual amount of accessible video memory. -- arvind ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf