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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4D43C00140 for ; Fri, 12 Aug 2022 15:02:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235840AbiHLPB7 (ORCPT ); Fri, 12 Aug 2022 11:01:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232014AbiHLPB6 (ORCPT ); Fri, 12 Aug 2022 11:01:58 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF855A7205; Fri, 12 Aug 2022 08:01:56 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id e69so1006579iof.5; Fri, 12 Aug 2022 08:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=FGZzrzAmz7xD4RA4VHluwmkiD3F2uePphL1xjVdsJ3GhjlcBiOZtb+SkrBPX5Iaum/ AL8LpzbmUA+aU+ZNLAJ4zO62b725uyUg7lFjZOZ6PNoYaazOFUwTInWceQZ+9WZHWA2x bvvfp5NAeGogvH9JosTO80P7YZ66uJj6T6L1QNm/wv3IjKxdaAUp1Ho5rvFTDqa7HU3h 27Ebqx+qWL6b7QbvDRG+ddIl6SPzJqFfAynfoo6F71Vg6/wA7kepzF8R7by9vSC0Fyhb CP/KtHEdsyHtw1ynFlWRrVIFudbfoXKjf5bLxIz+VyhKbQOq7LUECzSUCiLZHXdtXLDX cI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=yY+fp5i2SJwqAVL1GpGM34ALCrh8cSnXRgLu24sxNmom5K8i4yFKM83VcqjtCCs6lE o78C/MQtVoRXpG7gPMLGAWdqRvsDTCJBDYhlQIHfxiMPrCZEnltn5fygHe6wJ8Saa1dx DyU5ktHxdmkU0Xrzl3/Xxd6BrfNYEm+cUUQXdqLPmi8dsma308t7MtByJJijAERos3nH sNYRoWRNWUrYq6rUsNZvPNSgOgf9KQzOpaIhsbuJJ4aEIOkFBKtaYiQPxIZ827Gr5qhc N1fSOmBOW247R2L15D9WYBL2+Ca9AF8o+3tcYq9OdgmA6OEamq5YZSG3uK0v7VVslAvj 0uBA== X-Gm-Message-State: ACgBeo3WHIKPdgzBb7y+2iSXzJ9jLbdW0ADqXj9JgZDLC8Zhuwk1Gi8p nwYbPSkxpYqBlnvFiPeFLp3zMi7Y5D/mWm83T/s= X-Google-Smtp-Source: AA6agR5ROixpXWc2V2obN6+BACQm8lqAZVdAg9IyTZLBom1FQlCWofee8yj6lhWNvoQf5GcwigLflWEssMoEkaPktQ8= X-Received: by 2002:a05:6602:1cf:b0:5e9:74e7:6b01 with SMTP id w15-20020a05660201cf00b005e974e76b01mr1684235iot.127.1660316515970; Fri, 12 Aug 2022 08:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20220701090240.1896131-1-dmitry.osipenko@collabora.com> <20220701090240.1896131-3-dmitry.osipenko@collabora.com> <2bb95e80-b60a-36c0-76c8-a06833032c77@amd.com> <2a646ce4-c2ec-3b11-77a0-cc720afd6fe1@collabora.com> <9674d00e-c0d6-ceba-feab-5dc475bda694@collabora.com> <73b51dde-689f-64ce-a1c8-0d7c84a2ed66@collabora.com> In-Reply-To: From: Rob Clark Date: Fri, 12 Aug 2022 08:01:44 -0700 Message-ID: Subject: Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs To: Dmitry Osipenko Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Christian_K=C3=B6nig?= , David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Emil Velikov , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Linux Kernel Mailing List , dri-devel , "open list:VIRTIO GPU DRIVER" , linux-tegra@vger.kernel.org, Dmitry Osipenko , kernel@collabora.com, Daniel Vetter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote: > > On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko > wrote: > > > > On 8/11/22 02:19, Rob Clark wrote: > > > On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko > > > wrote: > > >> > > >> On 8/11/22 01:03, Rob Clark wrote: > > >>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko > > >>> wrote: > > >>>> > > >>>> On 8/10/22 18:08, Rob Clark wrote: > > >>>>> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter w= rote: > > >>>>>> > > >>>>>> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote: > > >>>>>>> On 7/6/22 00:48, Rob Clark wrote: > > >>>>>>>> On Tue, Jul 5, 2022 at 4:51 AM Christian K=C3=B6nig wrote: > > >>>>>>>>> > > >>>>>>>>> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko: > > >>>>>>>>>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpe= rs don't > > >>>>>>>>>> handle imported dma-bufs properly, which results in mapping = of something > > >>>>>>>>>> else than the imported dma-buf. On NVIDIA Tegra we get a har= d lockup when > > >>>>>>>>>> userspace writes to the memory mapping of a dma-buf that was= imported into > > >>>>>>>>>> Tegra's DRM GEM. > > >>>>>>>>>> > > >>>>>>>>>> Majority of DRM drivers prohibit mapping of the imported GEM= objects. > > >>>>>>>>>> Mapping of imported GEMs require special care from userspace= since it > > >>>>>>>>>> should sync dma-buf because mapping coherency of the exporte= r device may > > >>>>>>>>>> not match the DRM device. Let's prohibit the mapping for all= DRM drivers > > >>>>>>>>>> for consistency. > > >>>>>>>>>> > > >>>>>>>>>> Suggested-by: Thomas Hellstr=C3=B6m > > >>>>>>>>>> Signed-off-by: Dmitry Osipenko > > >>>>>>>>> > > >>>>>>>>> I'm pretty sure that this is the right approach, but it's cer= tainly more > > >>>>>>>>> than possible that somebody abused this already. > > >>>>>>>> > > >>>>>>>> I suspect that this is abused if you run deqp cts on android..= ie. all > > >>>>>>>> winsys buffers are dma-buf imports from gralloc. And then whe= n you > > >>>>>>>> hit readpix... > > >>>>>>>> > > >>>>>>>> You might only hit this in scenarios with separate gpu and dis= play (or > > >>>>>>>> dGPU+iGPU) because self-imports are handled differently in > > >>>>>>>> drm_gem_prime_import_dev().. and maybe not in cases where you = end up > > >>>>>>>> with a blit from tiled/compressed to linear.. maybe that narro= ws the > > >>>>>>>> scope enough to just fix it in userspace? > > >>>>>>> > > >>>>>>> Given that that only drivers which use DRM-SHMEM potentially co= uld've > > >>>>>>> map imported dma-bufs (Panfrost, Lima) and they already don't a= llow to > > >>>>>>> do that, I think we're good. > > >>>>>> > > >>>>>> So can I have an ack from Rob here or are there still questions = that this > > >>>>>> might go boom? > > >>>>>> > > >>>>>> Dmitry, since you have a bunch of patches merged now I think wou= ld also be > > >>>>>> good to get commit rights so you can drive this more yourself. I= 've asked > > >>>>>> Daniel Stone to help you out with getting that. > > >>>>> > > >>>>> I *think* we'd be ok with this on msm, mostly just by dumb luck. > > >>>>> Because the dma-buf's we import will be self-import. I'm less su= re > > >>>>> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a > > >>>>> special path for imported dma-bufs either, and in that case they = won't > > >>>>> be self-imports.. but I guess no one has tried to run android cts= on > > >>>>> panfrost). > > >>>> > > >>>> The last time I tried to mmap dma-buf imported to Panfrost didn't = work > > >>>> because Panfrost didn't implement something needed for that. I'll = need > > >>>> to take a look again because can't recall what it was. > > Upd: I re-checked Panfrost using today's linux-next and mapping of > > imported dma-buf works, I mapped imported buf from video decoder. > > Apparently previously I had some local kernel change that broke the map= ping. > > > > >>>>> What about something less drastic to start, like (apologies for > > >>>>> hand-edited patch): > > >>>>> > > >>>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.= c > > >>>>> index 86d670c71286..fc9ec42fa0ab 100644 > > >>>>> --- a/drivers/gpu/drm/drm_gem.c > > >>>>> +++ b/drivers/gpu/drm/drm_gem.c > > >>>>> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object > > >>>>> *obj, unsigned long obj_size, > > >>>>> { > > >>>>> int ret; > > >>>>> > > >>>>> + WARN_ON_ONCE(obj->import_attach); > > >>>> > > >>>> This will hang NVIDIA Tegra, which is what this patch fixed initia= lly. > > >>>> If neither of upstream DRM drivers need to map imported dma-bufs a= nd > > >>>> never needed, then why do we need this? > > >>> > > >>> oh, tegra isn't using shmem helpers? I assumed it was. Well my po= int > > >>> was to make a more targeted fail on tegra, and a WARN_ON for everyo= ne > > >>> else to make it clear that what they are doing is undefined behavio= r. > > >>> Because so far existing userspace (or well, panfrost and freedreno = at > > >>> least, those are the two I know or checked) don't make special case= s > > >>> for mmap'ing against the dmabuf fd against the dmabuf fd instead of > > >>> the drm device fd. > > >> > > >> It's not clear to me what bad Android does form yours comments. Does= it > > >> export dma-buf from GPU and then import it to GPU? If yes, then DRM = core > > >> has a check for the self-importing [1]. > > >> > > >> [1] > > >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_p= rime.c#L918 > > >> > > >> If you're meaning something else, then please explain in a more deta= ils. > > > > > > So, android/gralloc allocates buffers externally to the driver and > > > imports them into driver. (And that seems to not just be window > > > surfaces, but in cases random textures, etc) > > > > > > In the normal case these should be allocated from drm/msm so it shoul= d > > > hit [1].. this is the "dumb luck" I mentioned earlier. But I'm not > > > confident enough to say that there is no other case. > > > > > >> > > >>> I *think* it should work out that we don't hit this path with > > >>> freedreno but on android I can't really guarantee or prove it. So > > >>> your patch would potentially break existing working userspace. May= be > > >>> it is userspace that isn't portable (but OTOH it isn't like you are > > >>> going to be using freedreno on tegra). So why don't you go for a m= ore > > >>> targeted fix that only returns an error on hw where this is > > >>> problematic? > > >> > > >> That's what the first versions of the patch did and Christian sugges= ted > > >> that it's not a good approach. In fact it should be not only Tegra t= hat > > >> has a broken dma-buf mapping, but apparently OMAP driver too. > > > > > > Hmm, I guess I'm a bit more conservative when it comes to potentially > > > breaking userspace. > > > > If such userspace exists, then of course the mapping should continue to > > work. Still will be great to know what that userpsace is. > > Definitely existing mesa does not have a special mmap path for > imported dma-bufs (both in the case of panfrost and freedreno, I > didn't check any others). The only question is whether there is a > case where some app/test/etc imports a foreign dma-buf fd and then > does something that would trigger mmap'ing, like readpix. The other complication I noticed is that we don't seem to keep around the fd after importing to a GEM handle. And I could imagine that doing so could cause issues with too many fd's. So I guess the best thing is to keep the status quo and let drivers that cannot mmap imported buffers just fail mmap? BR, -R > BR, > -R > > > Alright, let's keep the dma-buf mapping as-is for now. I'll fix just th= e > > Tegra driver then. > > > > -- > > Best regards, > > Dmitry 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 Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BF03AC25B0E for ; Fri, 12 Aug 2022 15:02:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3FBDB83DF8; Fri, 12 Aug 2022 15:02:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3FBDB83DF8 Authentication-Results: smtp1.osuosl.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=FGZzrzAm X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGeq6V-dHTbi; Fri, 12 Aug 2022 15:02:01 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 877A083DF0; Fri, 12 Aug 2022 15:02:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 877A083DF0 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 51FD6C0033; Fri, 12 Aug 2022 15:02:00 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C264FC002D for ; Fri, 12 Aug 2022 15:01:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 83CD9605EA for ; Fri, 12 Aug 2022 15:01:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 83CD9605EA Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=FGZzrzAm X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STY-9BGx8VCI for ; Fri, 12 Aug 2022 15:01:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1AEF5605B1 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1AEF5605B1 for ; Fri, 12 Aug 2022 15:01:56 +0000 (UTC) Received: by mail-io1-xd33.google.com with SMTP id g15so1029262iob.0 for ; Fri, 12 Aug 2022 08:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=FGZzrzAmz7xD4RA4VHluwmkiD3F2uePphL1xjVdsJ3GhjlcBiOZtb+SkrBPX5Iaum/ AL8LpzbmUA+aU+ZNLAJ4zO62b725uyUg7lFjZOZ6PNoYaazOFUwTInWceQZ+9WZHWA2x bvvfp5NAeGogvH9JosTO80P7YZ66uJj6T6L1QNm/wv3IjKxdaAUp1Ho5rvFTDqa7HU3h 27Ebqx+qWL6b7QbvDRG+ddIl6SPzJqFfAynfoo6F71Vg6/wA7kepzF8R7by9vSC0Fyhb CP/KtHEdsyHtw1ynFlWRrVIFudbfoXKjf5bLxIz+VyhKbQOq7LUECzSUCiLZHXdtXLDX cI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=mbY7PdjWTgcflTw83FCx7YejAJxf3BaJrwdKYtUYXIjYpbYuLpgPhq/PONrLEza87h RkVafPg4ehZIIhdselqgKBwXNIR/VrbtDJx3ZP/FESCGCOlwIjLxGZEb7y0fjTTNKXjx p9+kOYbnhXfXNN8ZRBu5dUhi7bbFPJcj1qw6dZqeCfI8Lce069Zrs+HEv18PoKkapoNP sX3s3Uae0A+Sz/qx1EG9AzD4nHpkHGLCiPUj9FQSvRwS/zdWBn/BTKj56T7BPKPQtNWx pc+OEvaCsgOMlCIDvZGzEQ2UM25TIcEWqodh5aJDZTDm1WhbA4nVggmaUki46KnJzeRa 17zA== X-Gm-Message-State: ACgBeo1+8eN6M9mURjiELtSx4Mn10qUclHvU4DQjMdA7Euqf9kxYZFeh pIWK7BY5LHJ+6fXNLk2Mo75KnGygzcITiosv0/A= X-Google-Smtp-Source: AA6agR5ROixpXWc2V2obN6+BACQm8lqAZVdAg9IyTZLBom1FQlCWofee8yj6lhWNvoQf5GcwigLflWEssMoEkaPktQ8= X-Received: by 2002:a05:6602:1cf:b0:5e9:74e7:6b01 with SMTP id w15-20020a05660201cf00b005e974e76b01mr1684235iot.127.1660316515970; Fri, 12 Aug 2022 08:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20220701090240.1896131-1-dmitry.osipenko@collabora.com> <20220701090240.1896131-3-dmitry.osipenko@collabora.com> <2bb95e80-b60a-36c0-76c8-a06833032c77@amd.com> <2a646ce4-c2ec-3b11-77a0-cc720afd6fe1@collabora.com> <9674d00e-c0d6-ceba-feab-5dc475bda694@collabora.com> <73b51dde-689f-64ce-a1c8-0d7c84a2ed66@collabora.com> In-Reply-To: From: Rob Clark Date: Fri, 12 Aug 2022 08:01:44 -0700 Message-ID: Subject: Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs To: Dmitry Osipenko Cc: kernel@collabora.com, dri-devel , =?UTF-8?Q?Christian_K=C3=B6nig?= , David Airlie , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Maarten Lankhorst , Linux Kernel Mailing List , Maxime Ripard , Gurchetan Singh , Emil Velikov , Thomas Zimmermann , linux-tegra@vger.kernel.org, Daniel Vetter , Dmitry Osipenko , "open list:VIRTIO GPU DRIVER" , Chia-I Wu X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" T24gRnJpLCBBdWcgMTIsIDIwMjIgYXQgNzo1NyBBTSBSb2IgQ2xhcmsgPHJvYmRjbGFya0BnbWFp bC5jb20+IHdyb3RlOgo+Cj4gT24gRnJpLCBBdWcgMTIsIDIwMjIgYXQgNDoyNiBBTSBEbWl0cnkg T3NpcGVua28KPiA8ZG1pdHJ5Lm9zaXBlbmtvQGNvbGxhYm9yYS5jb20+IHdyb3RlOgo+ID4KPiA+ IE9uIDgvMTEvMjIgMDI6MTksIFJvYiBDbGFyayB3cm90ZToKPiA+ID4gT24gV2VkLCBBdWcgMTAs IDIwMjIgYXQgMzoyMyBQTSBEbWl0cnkgT3NpcGVua28KPiA+ID4gPGRtaXRyeS5vc2lwZW5rb0Bj b2xsYWJvcmEuY29tPiB3cm90ZToKPiA+ID4+Cj4gPiA+PiBPbiA4LzExLzIyIDAxOjAzLCBSb2Ig Q2xhcmsgd3JvdGU6Cj4gPiA+Pj4gT24gV2VkLCBBdWcgMTAsIDIwMjIgYXQgMTI6MjYgUE0gRG1p dHJ5IE9zaXBlbmtvCj4gPiA+Pj4gPGRtaXRyeS5vc2lwZW5rb0Bjb2xsYWJvcmEuY29tPiB3cm90 ZToKPiA+ID4+Pj4KPiA+ID4+Pj4gT24gOC8xMC8yMiAxODowOCwgUm9iIENsYXJrIHdyb3RlOgo+ ID4gPj4+Pj4gT24gV2VkLCBBdWcgMTAsIDIwMjIgYXQgNDo0NyBBTSBEYW5pZWwgVmV0dGVyIDxk YW5pZWxAZmZ3bGwuY2g+IHdyb3RlOgo+ID4gPj4+Pj4+Cj4gPiA+Pj4+Pj4gT24gV2VkLCBKdWwg MDYsIDIwMjIgYXQgMTA6MDI6MDdBTSArMDMwMCwgRG1pdHJ5IE9zaXBlbmtvIHdyb3RlOgo+ID4g Pj4+Pj4+PiBPbiA3LzYvMjIgMDA6NDgsIFJvYiBDbGFyayB3cm90ZToKPiA+ID4+Pj4+Pj4+IE9u IFR1ZSwgSnVsIDUsIDIwMjIgYXQgNDo1MSBBTSBDaHJpc3RpYW4gS8O2bmlnIDxjaHJpc3RpYW4u a29lbmlnQGFtZC5jb20+IHdyb3RlOgo+ID4gPj4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+Pj4gQW0gMDEu MDcuMjIgdW0gMTE6MDIgc2NocmllYiBEbWl0cnkgT3NpcGVua286Cj4gPiA+Pj4+Pj4+Pj4+IERy aXZlcnMgdGhhdCB1c2UgZHJtX2dlbV9tbWFwKCkgYW5kIGRybV9nZW1fbW1hcF9vYmooKSBoZWxw ZXJzIGRvbid0Cj4gPiA+Pj4+Pj4+Pj4+IGhhbmRsZSBpbXBvcnRlZCBkbWEtYnVmcyBwcm9wZXJs eSwgd2hpY2ggcmVzdWx0cyBpbiBtYXBwaW5nIG9mIHNvbWV0aGluZwo+ID4gPj4+Pj4+Pj4+PiBl bHNlIHRoYW4gdGhlIGltcG9ydGVkIGRtYS1idWYuIE9uIE5WSURJQSBUZWdyYSB3ZSBnZXQgYSBo YXJkIGxvY2t1cCB3aGVuCj4gPiA+Pj4+Pj4+Pj4+IHVzZXJzcGFjZSB3cml0ZXMgdG8gdGhlIG1l bW9yeSBtYXBwaW5nIG9mIGEgZG1hLWJ1ZiB0aGF0IHdhcyBpbXBvcnRlZCBpbnRvCj4gPiA+Pj4+ Pj4+Pj4+IFRlZ3JhJ3MgRFJNIEdFTS4KPiA+ID4+Pj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+Pj4gTWFq b3JpdHkgb2YgRFJNIGRyaXZlcnMgcHJvaGliaXQgbWFwcGluZyBvZiB0aGUgaW1wb3J0ZWQgR0VN IG9iamVjdHMuCj4gPiA+Pj4+Pj4+Pj4+IE1hcHBpbmcgb2YgaW1wb3J0ZWQgR0VNcyByZXF1aXJl IHNwZWNpYWwgY2FyZSBmcm9tIHVzZXJzcGFjZSBzaW5jZSBpdAo+ID4gPj4+Pj4+Pj4+PiBzaG91 bGQgc3luYyBkbWEtYnVmIGJlY2F1c2UgbWFwcGluZyBjb2hlcmVuY3kgb2YgdGhlIGV4cG9ydGVy IGRldmljZSBtYXkKPiA+ID4+Pj4+Pj4+Pj4gbm90IG1hdGNoIHRoZSBEUk0gZGV2aWNlLiBMZXQn cyBwcm9oaWJpdCB0aGUgbWFwcGluZyBmb3IgYWxsIERSTSBkcml2ZXJzCj4gPiA+Pj4+Pj4+Pj4+ IGZvciBjb25zaXN0ZW5jeS4KPiA+ID4+Pj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+Pj4gU3VnZ2VzdGVk LWJ5OiBUaG9tYXMgSGVsbHN0csO2bSA8dGhvbWFzLmhlbGxzdHJvbUBsaW51eC5pbnRlbC5jb20+ Cj4gPiA+Pj4+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IERtaXRyeSBPc2lwZW5rbyA8ZG1pdHJ5Lm9z aXBlbmtvQGNvbGxhYm9yYS5jb20+Cj4gPiA+Pj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+PiBJJ20gcHJl dHR5IHN1cmUgdGhhdCB0aGlzIGlzIHRoZSByaWdodCBhcHByb2FjaCwgYnV0IGl0J3MgY2VydGFp bmx5IG1vcmUKPiA+ID4+Pj4+Pj4+PiB0aGFuIHBvc3NpYmxlIHRoYXQgc29tZWJvZHkgYWJ1c2Vk IHRoaXMgYWxyZWFkeS4KPiA+ID4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+PiBJIHN1c3BlY3QgdGhhdCB0 aGlzIGlzIGFidXNlZCBpZiB5b3UgcnVuIGRlcXAgY3RzIG9uIGFuZHJvaWQuLiBpZS4gYWxsCj4g PiA+Pj4+Pj4+PiB3aW5zeXMgYnVmZmVycyBhcmUgZG1hLWJ1ZiBpbXBvcnRzIGZyb20gZ3JhbGxv Yy4gIEFuZCB0aGVuIHdoZW4geW91Cj4gPiA+Pj4+Pj4+PiBoaXQgcmVhZHBpeC4uLgo+ID4gPj4+ Pj4+Pj4KPiA+ID4+Pj4+Pj4+IFlvdSBtaWdodCBvbmx5IGhpdCB0aGlzIGluIHNjZW5hcmlvcyB3 aXRoIHNlcGFyYXRlIGdwdSBhbmQgZGlzcGxheSAob3IKPiA+ID4+Pj4+Pj4+IGRHUFUraUdQVSkg YmVjYXVzZSBzZWxmLWltcG9ydHMgYXJlIGhhbmRsZWQgZGlmZmVyZW50bHkgaW4KPiA+ID4+Pj4+ Pj4+IGRybV9nZW1fcHJpbWVfaW1wb3J0X2RldigpLi4gYW5kIG1heWJlIG5vdCBpbiBjYXNlcyB3 aGVyZSB5b3UgZW5kIHVwCj4gPiA+Pj4+Pj4+PiB3aXRoIGEgYmxpdCBmcm9tIHRpbGVkL2NvbXBy ZXNzZWQgdG8gbGluZWFyLi4gbWF5YmUgdGhhdCBuYXJyb3dzIHRoZQo+ID4gPj4+Pj4+Pj4gc2Nv cGUgZW5vdWdoIHRvIGp1c3QgZml4IGl0IGluIHVzZXJzcGFjZT8KPiA+ID4+Pj4+Pj4KPiA+ID4+ Pj4+Pj4gR2l2ZW4gdGhhdCB0aGF0IG9ubHkgZHJpdmVycyB3aGljaCB1c2UgRFJNLVNITUVNIHBv dGVudGlhbGx5IGNvdWxkJ3ZlCj4gPiA+Pj4+Pj4+IG1hcCBpbXBvcnRlZCBkbWEtYnVmcyAoUGFu ZnJvc3QsIExpbWEpIGFuZCB0aGV5IGFscmVhZHkgZG9uJ3QgYWxsb3cgdG8KPiA+ID4+Pj4+Pj4g ZG8gdGhhdCwgSSB0aGluayB3ZSdyZSBnb29kLgo+ID4gPj4+Pj4+Cj4gPiA+Pj4+Pj4gU28gY2Fu IEkgaGF2ZSBhbiBhY2sgZnJvbSBSb2IgaGVyZSBvciBhcmUgdGhlcmUgc3RpbGwgcXVlc3Rpb25z IHRoYXQgdGhpcwo+ID4gPj4+Pj4+IG1pZ2h0IGdvIGJvb20/Cj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+ PiBEbWl0cnksIHNpbmNlIHlvdSBoYXZlIGEgYnVuY2ggb2YgcGF0Y2hlcyBtZXJnZWQgbm93IEkg dGhpbmsgd291bGQgYWxzbyBiZQo+ID4gPj4+Pj4+IGdvb2QgdG8gZ2V0IGNvbW1pdCByaWdodHMg c28geW91IGNhbiBkcml2ZSB0aGlzIG1vcmUgeW91cnNlbGYuIEkndmUgYXNrZWQKPiA+ID4+Pj4+ PiBEYW5pZWwgU3RvbmUgdG8gaGVscCB5b3Ugb3V0IHdpdGggZ2V0dGluZyB0aGF0Lgo+ID4gPj4+ Pj4KPiA+ID4+Pj4+IEkgKnRoaW5rKiB3ZSdkIGJlIG9rIHdpdGggdGhpcyBvbiBtc20sIG1vc3Rs eSBqdXN0IGJ5IGR1bWIgbHVjay4KPiA+ID4+Pj4+IEJlY2F1c2UgdGhlIGRtYS1idWYncyB3ZSBp bXBvcnQgd2lsbCBiZSBzZWxmLWltcG9ydC4gIEknbSBsZXNzIHN1cmUKPiA+ID4+Pj4+IGFib3V0 IHBhbmZyb3N0IChzcmMvcGFuZnJvc3QvbGliL3Bhbl9iby5jIGRvZXNuJ3Qgc2VlbSB0byBoYXZl IGEKPiA+ID4+Pj4+IHNwZWNpYWwgcGF0aCBmb3IgaW1wb3J0ZWQgZG1hLWJ1ZnMgZWl0aGVyLCBh bmQgaW4gdGhhdCBjYXNlIHRoZXkgd29uJ3QKPiA+ID4+Pj4+IGJlIHNlbGYtaW1wb3J0cy4uIGJ1 dCBJIGd1ZXNzIG5vIG9uZSBoYXMgdHJpZWQgdG8gcnVuIGFuZHJvaWQgY3RzIG9uCj4gPiA+Pj4+ PiBwYW5mcm9zdCkuCj4gPiA+Pj4+Cj4gPiA+Pj4+IFRoZSBsYXN0IHRpbWUgSSB0cmllZCB0byBt bWFwIGRtYS1idWYgaW1wb3J0ZWQgdG8gUGFuZnJvc3QgZGlkbid0IHdvcmsKPiA+ID4+Pj4gYmVj YXVzZSBQYW5mcm9zdCBkaWRuJ3QgaW1wbGVtZW50IHNvbWV0aGluZyBuZWVkZWQgZm9yIHRoYXQu IEknbGwgbmVlZAo+ID4gPj4+PiB0byB0YWtlIGEgbG9vayBhZ2FpbiBiZWNhdXNlIGNhbid0IHJl Y2FsbCB3aGF0IGl0IHdhcy4KPiA+IFVwZDogSSByZS1jaGVja2VkIFBhbmZyb3N0IHVzaW5nIHRv ZGF5J3MgbGludXgtbmV4dCBhbmQgbWFwcGluZyBvZgo+ID4gaW1wb3J0ZWQgZG1hLWJ1ZiB3b3Jr cywgSSBtYXBwZWQgaW1wb3J0ZWQgYnVmIGZyb20gdmlkZW8gZGVjb2Rlci4KPiA+IEFwcGFyZW50 bHkgcHJldmlvdXNseSBJIGhhZCBzb21lIGxvY2FsIGtlcm5lbCBjaGFuZ2UgdGhhdCBicm9rZSB0 aGUgbWFwcGluZy4KPiA+Cj4gPiA+Pj4+PiBXaGF0IGFib3V0IHNvbWV0aGluZyBsZXNzIGRyYXN0 aWMgdG8gc3RhcnQsIGxpa2UgKGFwb2xvZ2llcyBmb3IKPiA+ID4+Pj4+IGhhbmQtZWRpdGVkIHBh dGNoKToKPiA+ID4+Pj4+Cj4gPiA+Pj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL2Ry bV9nZW0uYyBiL2RyaXZlcnMvZ3B1L2RybS9kcm1fZ2VtLmMKPiA+ID4+Pj4+IGluZGV4IDg2ZDY3 MGM3MTI4Ni4uZmM5ZWM0MmZhMGFiIDEwMDY0NAo+ID4gPj4+Pj4gLS0tIGEvZHJpdmVycy9ncHUv ZHJtL2RybV9nZW0uYwo+ID4gPj4+Pj4gKysrIGIvZHJpdmVycy9ncHUvZHJtL2RybV9nZW0uYwo+ ID4gPj4+Pj4gQEAgLTEwMzQsNiArMTAzNCwxMCBAQCBpbnQgZHJtX2dlbV9tbWFwX29iaihzdHJ1 Y3QgZHJtX2dlbV9vYmplY3QKPiA+ID4+Pj4+ICpvYmosIHVuc2lnbmVkIGxvbmcgb2JqX3NpemUs Cj4gPiA+Pj4+PiAgewo+ID4gPj4+Pj4gICAgICAgICBpbnQgcmV0Owo+ID4gPj4+Pj4KPiA+ID4+ Pj4+ICsgICAgICAgV0FSTl9PTl9PTkNFKG9iai0+aW1wb3J0X2F0dGFjaCk7Cj4gPiA+Pj4+Cj4g PiA+Pj4+IFRoaXMgd2lsbCBoYW5nIE5WSURJQSBUZWdyYSwgd2hpY2ggaXMgd2hhdCB0aGlzIHBh dGNoIGZpeGVkIGluaXRpYWxseS4KPiA+ID4+Pj4gSWYgbmVpdGhlciBvZiB1cHN0cmVhbSBEUk0g ZHJpdmVycyBuZWVkIHRvIG1hcCBpbXBvcnRlZCBkbWEtYnVmcyBhbmQKPiA+ID4+Pj4gbmV2ZXIg bmVlZGVkLCB0aGVuIHdoeSBkbyB3ZSBuZWVkIHRoaXM/Cj4gPiA+Pj4KPiA+ID4+PiBvaCwgdGVn cmEgaXNuJ3QgdXNpbmcgc2htZW0gaGVscGVycz8gIEkgYXNzdW1lZCBpdCB3YXMuICBXZWxsIG15 IHBvaW50Cj4gPiA+Pj4gd2FzIHRvIG1ha2UgYSBtb3JlIHRhcmdldGVkIGZhaWwgb24gdGVncmEs IGFuZCBhIFdBUk5fT04gZm9yIGV2ZXJ5b25lCj4gPiA+Pj4gZWxzZSB0byBtYWtlIGl0IGNsZWFy IHRoYXQgd2hhdCB0aGV5IGFyZSBkb2luZyBpcyB1bmRlZmluZWQgYmVoYXZpb3IuCj4gPiA+Pj4g QmVjYXVzZSBzbyBmYXIgZXhpc3RpbmcgdXNlcnNwYWNlIChvciB3ZWxsLCBwYW5mcm9zdCBhbmQg ZnJlZWRyZW5vIGF0Cj4gPiA+Pj4gbGVhc3QsIHRob3NlIGFyZSB0aGUgdHdvIEkga25vdyBvciBj aGVja2VkKSBkb24ndCBtYWtlIHNwZWNpYWwgY2FzZXMKPiA+ID4+PiBmb3IgbW1hcCdpbmcgYWdh aW5zdCB0aGUgZG1hYnVmIGZkIGFnYWluc3QgdGhlIGRtYWJ1ZiBmZCBpbnN0ZWFkIG9mCj4gPiA+ Pj4gdGhlIGRybSBkZXZpY2UgZmQuCj4gPiA+Pgo+ID4gPj4gSXQncyBub3QgY2xlYXIgdG8gbWUg d2hhdCBiYWQgQW5kcm9pZCBkb2VzIGZvcm0geW91cnMgY29tbWVudHMuIERvZXMgaXQKPiA+ID4+ IGV4cG9ydCBkbWEtYnVmIGZyb20gR1BVIGFuZCB0aGVuIGltcG9ydCBpdCB0byBHUFU/IElmIHll cywgdGhlbiBEUk0gY29yZQo+ID4gPj4gaGFzIGEgY2hlY2sgZm9yIHRoZSBzZWxmLWltcG9ydGlu ZyBbMV0uCj4gPiA+Pgo+ID4gPj4gWzFdCj4gPiA+PiBodHRwczovL2VsaXhpci5ib290bGluLmNv bS9saW51eC9sYXRlc3Qvc291cmNlL2RyaXZlcnMvZ3B1L2RybS9kcm1fcHJpbWUuYyNMOTE4Cj4g PiA+Pgo+ID4gPj4gSWYgeW91J3JlIG1lYW5pbmcgc29tZXRoaW5nIGVsc2UsIHRoZW4gcGxlYXNl IGV4cGxhaW4gaW4gYSBtb3JlIGRldGFpbHMuCj4gPiA+Cj4gPiA+IFNvLCBhbmRyb2lkL2dyYWxs b2MgYWxsb2NhdGVzIGJ1ZmZlcnMgZXh0ZXJuYWxseSB0byB0aGUgZHJpdmVyIGFuZAo+ID4gPiBp bXBvcnRzIHRoZW0gaW50byBkcml2ZXIuICAoQW5kIHRoYXQgc2VlbXMgdG8gbm90IGp1c3QgYmUg d2luZG93Cj4gPiA+IHN1cmZhY2VzLCBidXQgaW4gY2FzZXMgcmFuZG9tIHRleHR1cmVzLCBldGMp Cj4gPiA+Cj4gPiA+IEluIHRoZSBub3JtYWwgY2FzZSB0aGVzZSBzaG91bGQgYmUgYWxsb2NhdGVk IGZyb20gZHJtL21zbSBzbyBpdCBzaG91bGQKPiA+ID4gaGl0IFsxXS4uIHRoaXMgaXMgdGhlICJk dW1iIGx1Y2siIEkgbWVudGlvbmVkIGVhcmxpZXIuICBCdXQgSSdtIG5vdAo+ID4gPiBjb25maWRl bnQgZW5vdWdoIHRvIHNheSB0aGF0IHRoZXJlIGlzIG5vIG90aGVyIGNhc2UuCj4gPiA+Cj4gPiA+ Pgo+ID4gPj4+IEkgKnRoaW5rKiBpdCBzaG91bGQgd29yayBvdXQgdGhhdCB3ZSBkb24ndCBoaXQg dGhpcyBwYXRoIHdpdGgKPiA+ID4+PiBmcmVlZHJlbm8gYnV0IG9uIGFuZHJvaWQgSSBjYW4ndCBy ZWFsbHkgZ3VhcmFudGVlIG9yIHByb3ZlIGl0LiAgU28KPiA+ID4+PiB5b3VyIHBhdGNoIHdvdWxk IHBvdGVudGlhbGx5IGJyZWFrIGV4aXN0aW5nIHdvcmtpbmcgdXNlcnNwYWNlLiAgTWF5YmUKPiA+ ID4+PiBpdCBpcyB1c2Vyc3BhY2UgdGhhdCBpc24ndCBwb3J0YWJsZSAoYnV0IE9UT0ggaXQgaXNu J3QgbGlrZSB5b3UgYXJlCj4gPiA+Pj4gZ29pbmcgdG8gYmUgdXNpbmcgZnJlZWRyZW5vIG9uIHRl Z3JhKS4gIFNvIHdoeSBkb24ndCB5b3UgZ28gZm9yIGEgbW9yZQo+ID4gPj4+IHRhcmdldGVkIGZp eCB0aGF0IG9ubHkgcmV0dXJucyBhbiBlcnJvciBvbiBodyB3aGVyZSB0aGlzIGlzCj4gPiA+Pj4g cHJvYmxlbWF0aWM/Cj4gPiA+Pgo+ID4gPj4gVGhhdCdzIHdoYXQgdGhlIGZpcnN0IHZlcnNpb25z IG9mIHRoZSBwYXRjaCBkaWQgYW5kIENocmlzdGlhbiBzdWdnZXN0ZWQKPiA+ID4+IHRoYXQgaXQn cyBub3QgYSBnb29kIGFwcHJvYWNoLiBJbiBmYWN0IGl0IHNob3VsZCBiZSBub3Qgb25seSBUZWdy YSB0aGF0Cj4gPiA+PiBoYXMgYSBicm9rZW4gZG1hLWJ1ZiBtYXBwaW5nLCBidXQgYXBwYXJlbnRs eSBPTUFQIGRyaXZlciB0b28uCj4gPiA+Cj4gPiA+IEhtbSwgSSBndWVzcyBJJ20gYSBiaXQgbW9y ZSBjb25zZXJ2YXRpdmUgd2hlbiBpdCBjb21lcyB0byBwb3RlbnRpYWxseQo+ID4gPiBicmVha2lu ZyB1c2Vyc3BhY2UuCj4gPgo+ID4gSWYgc3VjaCB1c2Vyc3BhY2UgZXhpc3RzLCB0aGVuIG9mIGNv dXJzZSB0aGUgbWFwcGluZyBzaG91bGQgY29udGludWUgdG8KPiA+IHdvcmsuIFN0aWxsIHdpbGwg YmUgZ3JlYXQgdG8ga25vdyB3aGF0IHRoYXQgdXNlcnBzYWNlIGlzLgo+Cj4gRGVmaW5pdGVseSBl eGlzdGluZyBtZXNhIGRvZXMgbm90IGhhdmUgYSBzcGVjaWFsIG1tYXAgcGF0aCBmb3IKPiBpbXBv cnRlZCBkbWEtYnVmcyAoYm90aCBpbiB0aGUgY2FzZSBvZiBwYW5mcm9zdCBhbmQgZnJlZWRyZW5v LCBJCj4gZGlkbid0IGNoZWNrIGFueSBvdGhlcnMpLiAgVGhlIG9ubHkgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGVyZSBpcyBhCj4gY2FzZSB3aGVyZSBzb21lIGFwcC90ZXN0L2V0YyBpbXBvcnRzIGEg Zm9yZWlnbiBkbWEtYnVmIGZkIGFuZCB0aGVuCj4gZG9lcyBzb21ldGhpbmcgdGhhdCB3b3VsZCB0 cmlnZ2VyIG1tYXAnaW5nLCBsaWtlIHJlYWRwaXguCgpUaGUgb3RoZXIgY29tcGxpY2F0aW9uIEkg bm90aWNlZCBpcyB0aGF0IHdlIGRvbid0IHNlZW0gdG8ga2VlcCBhcm91bmQKdGhlIGZkIGFmdGVy IGltcG9ydGluZyB0byBhIEdFTSBoYW5kbGUuICBBbmQgSSBjb3VsZCBpbWFnaW5lIHRoYXQKZG9p bmcgc28gY291bGQgY2F1c2UgaXNzdWVzIHdpdGggdG9vIG1hbnkgZmQncy4gIFNvIEkgZ3Vlc3Mg dGhlIGJlc3QKdGhpbmcgaXMgdG8ga2VlcCB0aGUgc3RhdHVzIHF1byBhbmQgbGV0IGRyaXZlcnMg dGhhdCBjYW5ub3QgbW1hcAppbXBvcnRlZCBidWZmZXJzIGp1c3QgZmFpbCBtbWFwPwoKQlIsCi1S Cgo+IEJSLAo+IC1SCj4KPiA+IEFscmlnaHQsIGxldCdzIGtlZXAgdGhlIGRtYS1idWYgbWFwcGlu ZyBhcy1pcyBmb3Igbm93LiBJJ2xsIGZpeCBqdXN0IHRoZQo+ID4gVGVncmEgZHJpdmVyIHRoZW4u Cj4gPgo+ID4gLS0KPiA+IEJlc3QgcmVnYXJkcywKPiA+IERtaXRyeQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpWaXJ0dWFsaXphdGlvbiBtYWlsaW5nIGxp c3QKVmlydHVhbGl6YXRpb25AbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0 cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxtYW4vbGlzdGluZm8vdmlydHVhbGl6YXRpb24= 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CECACC00140 for ; Fri, 12 Aug 2022 15:02:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E2EA9B5EA9; Fri, 12 Aug 2022 15:02:04 +0000 (UTC) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 11EB8B5E75 for ; Fri, 12 Aug 2022 15:01:58 +0000 (UTC) Received: by mail-io1-xd2d.google.com with SMTP id g15so1029298iob.0 for ; Fri, 12 Aug 2022 08:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=FGZzrzAmz7xD4RA4VHluwmkiD3F2uePphL1xjVdsJ3GhjlcBiOZtb+SkrBPX5Iaum/ AL8LpzbmUA+aU+ZNLAJ4zO62b725uyUg7lFjZOZ6PNoYaazOFUwTInWceQZ+9WZHWA2x bvvfp5NAeGogvH9JosTO80P7YZ66uJj6T6L1QNm/wv3IjKxdaAUp1Ho5rvFTDqa7HU3h 27Ebqx+qWL6b7QbvDRG+ddIl6SPzJqFfAynfoo6F71Vg6/wA7kepzF8R7by9vSC0Fyhb CP/KtHEdsyHtw1ynFlWRrVIFudbfoXKjf5bLxIz+VyhKbQOq7LUECzSUCiLZHXdtXLDX cI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=fFuoNXojTyZBhITwfY3HSSwwf07NNvFdh9I4FLMCELc=; b=6SLVWV21qeomBcRDofvSzeCz68ZUviLg3Lbgyazox4Y+tHNxBMJFKSwE4Vej1FXU1q a8HEuoFCNukSONqBZpsZJsdBNcXDBXVLjPtQnbT86PkOXnfk9yrUtUjc3yqDdDbTxO/P L8eVomVvXigk3J5NaRI3hiiQaocNGzpFlWnalFf91FQ4ZFKBOnLo3gFzMGuK7fd2hq2R RVLdCErAg5lDFhJ5mnXXyLSSaUZ1e8Or6pNB/bHzJnuqyX214q2WXvj/YoLXr55zHPft 2gyTS4rHLgIZvE+pFlCygSj3X08Szf2A8tob53rMWP8dhwngWF4h5hXSctcGTrTcfhZU GWew== X-Gm-Message-State: ACgBeo0FR6mNfcY9MbfInUTrlzESawKEJ2DTFU1ndDAbIWDsetV6jxsm oKsq3EV8xbOy6cTnUEnHo1FWxwPZfUFM3sTM178= X-Google-Smtp-Source: AA6agR5ROixpXWc2V2obN6+BACQm8lqAZVdAg9IyTZLBom1FQlCWofee8yj6lhWNvoQf5GcwigLflWEssMoEkaPktQ8= X-Received: by 2002:a05:6602:1cf:b0:5e9:74e7:6b01 with SMTP id w15-20020a05660201cf00b005e974e76b01mr1684235iot.127.1660316515970; Fri, 12 Aug 2022 08:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20220701090240.1896131-1-dmitry.osipenko@collabora.com> <20220701090240.1896131-3-dmitry.osipenko@collabora.com> <2bb95e80-b60a-36c0-76c8-a06833032c77@amd.com> <2a646ce4-c2ec-3b11-77a0-cc720afd6fe1@collabora.com> <9674d00e-c0d6-ceba-feab-5dc475bda694@collabora.com> <73b51dde-689f-64ce-a1c8-0d7c84a2ed66@collabora.com> In-Reply-To: From: Rob Clark Date: Fri, 12 Aug 2022 08:01:44 -0700 Message-ID: Subject: Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs To: Dmitry Osipenko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel@collabora.com, dri-devel , =?UTF-8?Q?Christian_K=C3=B6nig?= , David Airlie , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Linux Kernel Mailing List , Gurchetan Singh , Emil Velikov , Gerd Hoffmann , Thomas Zimmermann , linux-tegra@vger.kernel.org, Dmitry Osipenko , "open list:VIRTIO GPU DRIVER" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote: > > On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko > wrote: > > > > On 8/11/22 02:19, Rob Clark wrote: > > > On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko > > > wrote: > > >> > > >> On 8/11/22 01:03, Rob Clark wrote: > > >>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko > > >>> wrote: > > >>>> > > >>>> On 8/10/22 18:08, Rob Clark wrote: > > >>>>> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter w= rote: > > >>>>>> > > >>>>>> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote: > > >>>>>>> On 7/6/22 00:48, Rob Clark wrote: > > >>>>>>>> On Tue, Jul 5, 2022 at 4:51 AM Christian K=C3=B6nig wrote: > > >>>>>>>>> > > >>>>>>>>> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko: > > >>>>>>>>>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpe= rs don't > > >>>>>>>>>> handle imported dma-bufs properly, which results in mapping = of something > > >>>>>>>>>> else than the imported dma-buf. On NVIDIA Tegra we get a har= d lockup when > > >>>>>>>>>> userspace writes to the memory mapping of a dma-buf that was= imported into > > >>>>>>>>>> Tegra's DRM GEM. > > >>>>>>>>>> > > >>>>>>>>>> Majority of DRM drivers prohibit mapping of the imported GEM= objects. > > >>>>>>>>>> Mapping of imported GEMs require special care from userspace= since it > > >>>>>>>>>> should sync dma-buf because mapping coherency of the exporte= r device may > > >>>>>>>>>> not match the DRM device. Let's prohibit the mapping for all= DRM drivers > > >>>>>>>>>> for consistency. > > >>>>>>>>>> > > >>>>>>>>>> Suggested-by: Thomas Hellstr=C3=B6m > > >>>>>>>>>> Signed-off-by: Dmitry Osipenko > > >>>>>>>>> > > >>>>>>>>> I'm pretty sure that this is the right approach, but it's cer= tainly more > > >>>>>>>>> than possible that somebody abused this already. > > >>>>>>>> > > >>>>>>>> I suspect that this is abused if you run deqp cts on android..= ie. all > > >>>>>>>> winsys buffers are dma-buf imports from gralloc. And then whe= n you > > >>>>>>>> hit readpix... > > >>>>>>>> > > >>>>>>>> You might only hit this in scenarios with separate gpu and dis= play (or > > >>>>>>>> dGPU+iGPU) because self-imports are handled differently in > > >>>>>>>> drm_gem_prime_import_dev().. and maybe not in cases where you = end up > > >>>>>>>> with a blit from tiled/compressed to linear.. maybe that narro= ws the > > >>>>>>>> scope enough to just fix it in userspace? > > >>>>>>> > > >>>>>>> Given that that only drivers which use DRM-SHMEM potentially co= uld've > > >>>>>>> map imported dma-bufs (Panfrost, Lima) and they already don't a= llow to > > >>>>>>> do that, I think we're good. > > >>>>>> > > >>>>>> So can I have an ack from Rob here or are there still questions = that this > > >>>>>> might go boom? > > >>>>>> > > >>>>>> Dmitry, since you have a bunch of patches merged now I think wou= ld also be > > >>>>>> good to get commit rights so you can drive this more yourself. I= 've asked > > >>>>>> Daniel Stone to help you out with getting that. > > >>>>> > > >>>>> I *think* we'd be ok with this on msm, mostly just by dumb luck. > > >>>>> Because the dma-buf's we import will be self-import. I'm less su= re > > >>>>> about panfrost (src/panfrost/lib/pan_bo.c doesn't seem to have a > > >>>>> special path for imported dma-bufs either, and in that case they = won't > > >>>>> be self-imports.. but I guess no one has tried to run android cts= on > > >>>>> panfrost). > > >>>> > > >>>> The last time I tried to mmap dma-buf imported to Panfrost didn't = work > > >>>> because Panfrost didn't implement something needed for that. I'll = need > > >>>> to take a look again because can't recall what it was. > > Upd: I re-checked Panfrost using today's linux-next and mapping of > > imported dma-buf works, I mapped imported buf from video decoder. > > Apparently previously I had some local kernel change that broke the map= ping. > > > > >>>>> What about something less drastic to start, like (apologies for > > >>>>> hand-edited patch): > > >>>>> > > >>>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.= c > > >>>>> index 86d670c71286..fc9ec42fa0ab 100644 > > >>>>> --- a/drivers/gpu/drm/drm_gem.c > > >>>>> +++ b/drivers/gpu/drm/drm_gem.c > > >>>>> @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object > > >>>>> *obj, unsigned long obj_size, > > >>>>> { > > >>>>> int ret; > > >>>>> > > >>>>> + WARN_ON_ONCE(obj->import_attach); > > >>>> > > >>>> This will hang NVIDIA Tegra, which is what this patch fixed initia= lly. > > >>>> If neither of upstream DRM drivers need to map imported dma-bufs a= nd > > >>>> never needed, then why do we need this? > > >>> > > >>> oh, tegra isn't using shmem helpers? I assumed it was. Well my po= int > > >>> was to make a more targeted fail on tegra, and a WARN_ON for everyo= ne > > >>> else to make it clear that what they are doing is undefined behavio= r. > > >>> Because so far existing userspace (or well, panfrost and freedreno = at > > >>> least, those are the two I know or checked) don't make special case= s > > >>> for mmap'ing against the dmabuf fd against the dmabuf fd instead of > > >>> the drm device fd. > > >> > > >> It's not clear to me what bad Android does form yours comments. Does= it > > >> export dma-buf from GPU and then import it to GPU? If yes, then DRM = core > > >> has a check for the self-importing [1]. > > >> > > >> [1] > > >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_p= rime.c#L918 > > >> > > >> If you're meaning something else, then please explain in a more deta= ils. > > > > > > So, android/gralloc allocates buffers externally to the driver and > > > imports them into driver. (And that seems to not just be window > > > surfaces, but in cases random textures, etc) > > > > > > In the normal case these should be allocated from drm/msm so it shoul= d > > > hit [1].. this is the "dumb luck" I mentioned earlier. But I'm not > > > confident enough to say that there is no other case. > > > > > >> > > >>> I *think* it should work out that we don't hit this path with > > >>> freedreno but on android I can't really guarantee or prove it. So > > >>> your patch would potentially break existing working userspace. May= be > > >>> it is userspace that isn't portable (but OTOH it isn't like you are > > >>> going to be using freedreno on tegra). So why don't you go for a m= ore > > >>> targeted fix that only returns an error on hw where this is > > >>> problematic? > > >> > > >> That's what the first versions of the patch did and Christian sugges= ted > > >> that it's not a good approach. In fact it should be not only Tegra t= hat > > >> has a broken dma-buf mapping, but apparently OMAP driver too. > > > > > > Hmm, I guess I'm a bit more conservative when it comes to potentially > > > breaking userspace. > > > > If such userspace exists, then of course the mapping should continue to > > work. Still will be great to know what that userpsace is. > > Definitely existing mesa does not have a special mmap path for > imported dma-bufs (both in the case of panfrost and freedreno, I > didn't check any others). The only question is whether there is a > case where some app/test/etc imports a foreign dma-buf fd and then > does something that would trigger mmap'ing, like readpix. The other complication I noticed is that we don't seem to keep around the fd after importing to a GEM handle. And I could imagine that doing so could cause issues with too many fd's. So I guess the best thing is to keep the status quo and let drivers that cannot mmap imported buffers just fail mmap? BR, -R > BR, > -R > > > Alright, let's keep the dma-buf mapping as-is for now. I'll fix just th= e > > Tegra driver then. > > > > -- > > Best regards, > > Dmitry