search for: deferenc

...awking.Zhang at amd.com>; Jason Gunthorpe <jgg at ziepe.ca>; Likun Gao ><Likun.Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- >devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing >MMU type > >The value of struct drm_device.ttm.type_vram can become -1 for unknown >types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >error when accessing struct nvif_mmu.type[]: Would this make more sense to just set the type_vram = 0 instead of -1? Mik...

...hang at amd.com>; Jason Gunthorpe <jgg at ziepe.ca>; Likun Gao ><Likun.Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- >devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing MMU type > >Hi > >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: >> >> >>> -----Original Message----- >>> From: Thomas Zimmermann <tzimmermann at suse.de> >>> Sent: Tuesday, November 10, 2020 8:37 AM >>> To: bskeggs at redhat.com;...

...t;alexander.deucher at amd.com>; >Dave Airlie <airlied at redhat.com>; Likun Gao <Likun.Gao at amd.com>; Felix >Kuehling <Felix.Kuehling at amd.com>; Hawking Zhang ><Hawking.Zhang at amd.com> >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when >deferencing MMU type > >On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J <michael.j.ruhl at intel.com> >wrote: >> >> >-----Original Message----- >> >From: Thomas Zimmermann <tzimmermann at suse.de> >> >Sent: Wednesday, November 11, 2020 7:08 AM >> &gt...

...Jason Gunthorpe <jgg at ziepe.ca>; Likun Gao > ><Likun.Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- > >devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org > >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when > >deferencing MMU type > > > >Hi > > > >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: > >> > >> > >>> -----Original Message----- > >>> From: Thomas Zimmermann <tzimmermann at suse.de> > >>> Sent: Tuesday, November 10, 2020 8:3...

...amd.com>; Jason Gunthorpe <jgg at ziepe.ca>; Likun Gao >> <Likun.Gao at amd.com>; virtualization at lists.linux-foundation.org; spice- >> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org >> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing >> MMU type >> >> The value of struct drm_device.ttm.type_vram can become -1 for unknown >> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds >> error when accessing struct nvif_mmu.type[]: > > Would this make more sense to just set the...

The value of struct drm_device.ttm.type_vram can become -1 for unknown types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds error when accessing struct nvif_mmu.type[]: [ 18.304116] ================================================================== [ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.320415] Read of

On Tue, Jan 27, 2015 at 8:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Ah, yes. You are right, we cannot always assume that %y would be zero in > > the second case. > > This wouldn't be the first time we've lost information that we could use > to > > optimize a program by transforming it. > > > > Do you think this result

Thanks a lot for your help Matthijs! :) basically this does the job quite nicely I think: for (llvm::GlobalVariable::use_iterator U = gv->use_begin(); U != gv->use_end(); ++U) { llvm::Instruction *I = llvm::cast<llvm::Instruction>(U); I->replaceAllUsesWith(constPtr); I->eraseFromParent(); } Cheers, Ralf Matthijs Kooijman wrote: > Hi Ralf, > > >> I

...): edid: fix off-by-one error in CEA mode numbering Michel Dänzer (1): present: Only send PresentCompleteNotify events to the presenting client Nikolay Martynov (1): XShmGetImage: fix censoring Olivier Fourdan (2): xwayland: Fix non-argb cursor conversion dix: avoid deferencing NULL PtrCtrl Peter Hutterer (1): config/udev: consider ID_INPUT_FOO=0 as 'unset' Thomas Hellstrom (3): glx: Work around a GLX_OML swap method in older dri drivers glx: Fix visual fbconfig matching with respect to swap method glx: Duplicate relevant fbconfigs for...

...have suddenly become private, seemingly > without fast, easy to use alternative. Is iterating through the parent > BasicBlock's iterator the only solution? Yes. The next/prev pointers have extra information encoded in them now, for efficiency. The iterator takes care of this for you, deferencing the raw pointer wouldn't work even if you could get to it. > * The same goes for BasicBlock::getNext()/Prev(). Is iterating through the > parent Function's iterator the only solution? Yep. > * CallInst's constructors do not accept vectors anymore, but a double > poi...

..." name; > + pr "\n"; > + List.iter ( > + fun { cbname } -> > + pr " Py_DECREF (user_data->%s);\n" cbname Oh, good fix. We were not previously incrementing the ref-count of the Python Callable, and could have ended up deferencing a garbage-collected object. > + ) cls; > + pr " free (user_data);\n"; > + pr "}\n"; > + pr "\n"; > + ); > + > | Flags n -> > pr " uint32_t %s_u32;\n" n; > pr &quo...

...lag. > The problem to solve is adequately defining "cannot hold". In the > strictest sense, you could say if %m = %n = 2^31 - 1 then the program > has UB; in effect defining "cannot hold" in the same way a location > you're loading from "cannot be" non-deferenceable. But, as David points > out, that would mean you cannot hoist arithmetic with the nuw/nsw tags > intact: > > if (foo) > %t = add nuw X Y > > since it could be that (X != 2^32-1 && Y != 2^32-1) only if foo == > true. Arithmetic with no-wrap flags effecti...

On Dec 6, 2011, at 3:29 PM, Peter Cooper wrote: > The best case i can think of is embedded developers needing to layout functions or globals in memory. > Currently they would have to resort to a linker script or assembly hacks for this. This proposal also requires extending object file formats and linkers, and this impacts a lot of people, so it would want a pretty compelling

On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Piotr, > > Thanks for posting this! First, a question. When you say, regarding i8* > @llvm.invariant.group.barrier(i8*): > > "Required to handle destructors, placement new and std::launder. Call of > this function will be put on the end of each of this functions" > > I

Hi, Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven: 1) Download llvm-gcc4 binary and llvm. Compile and run make check. I did a debug build on OSX 10.4.9 and everything went fine. Results of "make check" (see ppc.log): === Summary === # of expected passes 1630 # of unexpected failures 21 # of expected failures 2

...o grab handler without protocol support xwayland: Fix a segfault with pointer locking glamor: handle NULL source picture glamor: Avoid overflow between box32 and box16 box xwayland: add envvar XWAYLAND_NO_GLAMOR xwayland: Fix non-argb cursor conversion dix: avoid deferencing NULL PtrCtrl xwayland: Give up “cleanly“ on Wayland socket errors xwayland: avoid race condition on new keymap xwayland: Add optional xdg-output support xwayland: remove dirty window unconditionally on unrealize xwayland: place a manual redirect on windows Pekka Pa...

On 01/07/2015 05:33 PM, Chandler Carruth wrote: > How does this compare with classical approaches of loop peeling, > partitioning, fission, or whatever you might call it? I'm still developing a good sense for this, but let me lay out some observations. Fair warning, this is going to be long and rambling. Let's start with a toy example: while(c) { x = this->x; y =

As before, but this one has working Python bindings. OCaml still TBD. Rich.