linux-kernel - Re: [Intel-gfx] [PATCH v2 04/21] drm/i915/gt: Only invalidate TLBs exposed to user manipulation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220718180054.048929ef@maurocar-mobl2>
Date:   Mon, 18 Jul 2022 18:00:54 +0200
From:   Mauro Carvalho Chehab <mauro.chehab@...ux.intel.com>
To:     Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thomas Hellström 
        <thomas.hellstrom@...ux.intel.com>,
        David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Chris Wilson <chris.p.wilson@...el.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Dave Airlie <airlied@...hat.com>, stable@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 04/21] drm/i915/gt: Only invalidate TLBs
 exposed to user manipulation

On Mon, 18 Jul 2022 14:39:17 +0100
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com> wrote:

> On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
> > From: Chris Wilson <chris.p.wilson@...el.com>
> > 
> > Don't flush TLBs when the buffer is only used in the GGTT under full
> > control of the kernel, as there's no risk of concurrent access
> > and stale access from prefetch.
> > 
> > We only need to invalidate the TLB if they are accessible by the user.
> > That helps to reduce the performance regression introduced by TLB
> > invalidate logic.
> > 
> > Cc: stable@...r.kernel.org
> > Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")  
> 
> Do we really need or want stable and fixes on this one?
> 
> What do we think the performance improvement is, given there's very 
> little in GGTT, which is not mapped via PPGTT as well?
> 
> I think it is safe, but part of me would ideally not even want to think 
> about whether it is safe, if the performance improvement is 
> non-existent. Which I can't imagine how there would be?

Makes sense. Patch 6 actually ends removing the code doing
that, so I'll just fold this patch with patch 6, in order to
avoid adding something that will later be removed.

Regards,
Mauro