From patchwork Fri Aug 29 22:58:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cam Macdonell X-Patchwork-Id: 384415 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 1F0401400B9 for ; Sat, 30 Aug 2014 08:59:00 +1000 (EST) Received: from localhost ([::1]:44631 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNV8D-0003zD-GA for incoming@patchwork.ozlabs.org; Fri, 29 Aug 2014 18:58:57 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNV7j-0003JZ-B4 for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:58:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNV7e-0006av-P0 for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:58:27 -0400 Received: from mail-ob0-f180.google.com ([209.85.214.180]:48627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNV7e-0006Zp-Jy for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:58:22 -0400 Received: by mail-ob0-f180.google.com with SMTP id m8so2298946obr.25 for ; Fri, 29 Aug 2014 15:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=UxV/OByQguchj15tW33E4GsZvI2OpcWi+7FxRCGNYb8=; b=E69D770JkugOnWMgWZgofAxzk+llMSq5PbPx6GppvqKE1+FY7vS2RN+TTOjr2BEpDo zWdTIynM6qaXwwLznjDWkZ9e2WL1qJkC6hD+EDQ8HhOexnLXJOeG62btTsK/PTknp3rE UU8rs3V+pL97LcckdKaRhhzL6vuQOSuxQhfxba73u8mNk4zWuLv7Te74fGRk/shp62Df fFRAPd855UugMxSwGdde2zKSt65I9+OASEG38O+0Al3uaQBaHYFwf7NMj45r8QY1Ez4c sqAdsOpjl4ymAwzytHDiTvez5z8Vi2+zjnKIMfmDFpsOJdnNl0QPD9Y4YyrcwoyqXtYb 7k2w== X-Gm-Message-State: ALoCoQnidmw95LL9y406EAesLQYCfytl0ohXzUTTBhVwUBYA9dQzaP7h+WiHl+SkwlFP/mGc9z25 MIME-Version: 1.0 X-Received: by 10.182.102.97 with SMTP id fn1mr13072564obb.29.1409353100337; Fri, 29 Aug 2014 15:58:20 -0700 (PDT) Received: by 10.76.97.233 with HTTP; Fri, 29 Aug 2014 15:58:20 -0700 (PDT) Date: Fri, 29 Aug 2014 16:58:20 -0600 X-Google-Sender-Auth: S9JekrzBmkWwEWrgZByvTuQMr3Y Message-ID: From: Cam Macdonell To: "qemu-devel@nongnu.org Developers" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.214.180 Subject: [Qemu-devel] [RFC] mmap of BAR0 fails for ivshmem device X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hello, A bug was reported to me regarding mmaping of BAR0 in ivshmem. Indeed the mmap fails. This bug will affect those using the ivshmem server as BAR0 contains the registers for sending and receiving interrupts. It does not affect those mapping just the shared memory region. I have bisected to a patch from 3.12 commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1 Author: Linus Torvalds Date: Tue Oct 29 10:21:34 2013 -0700 Fix a few incorrectly checked [io_]remap_pfn_range() calls Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that really should use the vm_iomap_memory() helper. This trivially converts two of them to the helper, and comments about why the third one really needs to continue to use remap_pfn_range(), and adds the missing size check. Reported-by: Nico Golde Cc: stable@kernel.org Signed-off-by: Linus Torvalds vm_private_data; int mi = uio_find_mem_index(vma); + struct uio_mem *mem; if (mi < 0) return -EINVAL; + mem = idev->info->mem + mi; - vma->vm_ops = &uio_physical_vm_ops; + if (vma->vm_end - vma->vm_start > mem->size) + return -EINVAL; The last two lines shown above that check the length of the vm area cause the mmap to fail because ivshmem's BAR0 is only 256 bytes. One possible fix is to increase the size of BAR0 to the size of a page. Of course, I'd prefer to be able to fix this from my uio driver, but I'm not sure that is possible given the patch above changes the generic uio code. Advice is welcome. Finally, I apologize for not catching this bug earlier. It's an effect of not having the uio driver in the kernel. To avoid this in future, I will work to get the UIO ivshmem driver into the kernel. Sincerely, Cam