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: <20170127145215.uto6flnudabrpnmz@phenom.ffwll.local>
Date:   Fri, 27 Jan 2017 15:52:15 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Christian König <christian.koenig@....com>
Cc:     Thomas Hellstrom <thellstrom@...are.com>,
        Michel Dänzer <michel@...nzer.net>,
        Sinclair Yeh <syeh@...are.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

On Fri, Jan 27, 2017 at 03:43:18PM +0100, Christian König wrote:
> Am 27.01.2017 um 15:12 schrieb Daniel Vetter:
> > On Fri, Jan 27, 2017 at 09:22:47AM +0100, Christian König wrote:
> > > Am 27.01.2017 um 08:30 schrieb Daniel Vetter:
> > > > On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote:
> > > > > On 01/27/2017 03:29 AM, Michel Dänzer wrote:
> > > > > > On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> > > > > > > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> > > > > > > > Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> > > > > > > > > On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> > > > > > > > > > From: Michel Dänzer <michel.daenzer@....com>
> > > > > > > > > > 
> > > > > > > > > > The current caching state may not be tt_cached, even though the
> > > > > > > > > > placement contains TTM_PL_FLAG_CACHED, because placement can contain
> > > > > > > > > > multiple caching flags. Trying to swap out such a BO would trip up the
> > > > > > > > > > 
> > > > > > > > > > 	BUG_ON(ttm->caching_state != tt_cached);
> > > > > > > > > > 
> > > > > > > > > > in ttm_tt_swapout.
> > > > > > > > > > 
> > > > > > > > > > Cc: stable@...r.kernel.org
> > > > > > > > > > Signed-off-by: Michel Dänzer <michel.daenzer@....com>
> > > > > > > > > Reviewed-by: Thomas Hellstrom <thellstrom@...are.com>
> > > > > > > > Reviewed-by: Christian König <christian.koenig@....com>.
> > > > > > > Reviewed-by: Sinclair Yeh <syeh@...are.com>
> > > > > > Thanks for the reviews! Via which tree should we merge this?
> > > > > > 
> > > > > > 
> > > > > I don't maintain a TTM tree any longer. Let's check with Daniel if he
> > > > > can merge it through drm-misc.
> > > > I'm trying very hard not to get volunteered for ttm maintainer :-)
> > > Yeah, ok I volunteer. Wanted to take that over for a while anyway.
> > I guess you didn't use the dim magic to push it? The test integration tree
> > isn't rebuild ... Quickstart for the tooling:
> 
> Autsch! Do I have to use that or can I just go with my usual tool set?
> 
> Would probably be a pain to set this up everywhere here.

We use it both for convience (e.g. it auto-adds the sob if need, and the
patchwork link by default), and to catch mistakes (e.g. it checks that
you're not pushing patches outside of the scope of drm-misc or i915 to the
wrong tree). For drm-misc specifically there's also the 3 defconfigs
you're supposed to build test before pushing (unfornately not scripted
since distros can't even agree on what cross-compiler prefixes work for a
given platform). And since 1 month ago we have an arm-soc ttm-based
driver, so doing that for ttm patches is kinda a good idea too :-)

But right now the main thing is this integration tree magic to regenerate
drm-tip, and that's also what intel CI and kernelci from collabora beat
on. Long term I'd love to push all this onto the server-side (github makes
scipting a lot of this dead easy). But we're still stuck with patches
scribbled on stones with emailed patches and all that, so client-side
scripts are kinda needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ