From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3B4FC43381 for ; Mon, 18 Mar 2019 12:10:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A3B4D20857 for ; Mon, 18 Mar 2019 12:10:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbfCRMKT convert rfc822-to-8bit (ORCPT ); Mon, 18 Mar 2019 08:10:19 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:54788 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726730AbfCRMKT (ORCPT ); Mon, 18 Mar 2019 08:10:19 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 15927088-1500050 for multiple; Mon, 18 Mar 2019 12:10:15 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Tvrtko Ursulin , intel-gfx@lists.freedesktop.org From: Chris Wilson In-Reply-To: <155256387697.4168.12231881578088241451@skylake-alporthouse-com> Cc: stable@vger.kernel.org References: <20190314075829.16838-1-chris@chris-wilson.co.uk> <5572a2bf-1398-04e9-e681-5f7d4e8b9df9@linux.intel.com> <155256387697.4168.12231881578088241451@skylake-alporthouse-com> Message-ID: <155291101199.4168.4589198141475186842@skylake-alporthouse-com> User-Agent: alot/0.6 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sanity check mmap length against object size Date: Mon, 18 Mar 2019 12:10:12 +0000 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Quoting Chris Wilson (2019-03-14 11:44:37) > Quoting Tvrtko Ursulin (2019-03-14 11:33:43) > > I am only wondering what happens to reads/write to the trailing area? > > Does shmemfs expands the backing store for this mmap and we just end up > > with otherwise unused chunk at the end? > > My expectation would be that they generate a SIGBUS since the filp > should not be extended to cover the absent pages. So it would be the > equivalent of mmaping a file then calling ftruncate(0). Ok, having just checked, what actually happens is that shmemfs quite happily allocates the extra page beyond the end of the object and userspace can freely read/write into that address space with only the mere consequence that those pages are not mapped to the GPU. -Chris