search for: unpoisoning

Hi everyone, I ran into a false positive with memory sanitizer due to it not intercepting dlinfo. I tried to get started on writing such an interceptor, but dlinfo seems like an extraordinarily difficult function to intercept. The three considerations that I would like somebody to look at are: 1) How do we get the enum values to decide what kind of pointer dlinfo is getting. Ideally we'd

...or are these already unpoisoned by > > some other mechanism (e.g. because msan realizes they are part of a > loaded > > object file or unposions them on load - does this happen?). > > They are unpoisoned. All memory defaults to unpoisoned (shadow == 0), > and we take care of unpoisoning all memory we return to the OS. > > > > > Thanks, > > Keno > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/2f14e4a7/attachment.html>

On Tue, Apr 05, 2016 at 10:20:50AM +0200, Vlastimil Babka wrote: > On 04/05/2016 03:54 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > >> On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > >>> On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > ... > >>>>> > >>>>>

On Tue, Apr 05, 2016 at 10:20:50AM +0200, Vlastimil Babka wrote: > On 04/05/2016 03:54 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > >> On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > >>> On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > ... > >>>>> > >>>>>

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment saying which > >>> pin we are

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment saying which > >>> pin we are

On 04/05/2016 03:54 AM, Naoya Horiguchi wrote: > On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: >> On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: >>> On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > ... >>>>> >>>>> Also (but not your fault) the put_page() preceding >>>>> test_set_page_hwpoison(page))

...s a 1-to-1 mapping between threads and plugins. * 1-to-1 mapping: Since the plugin owns the thread stack, all of the corresponding shadow can be initially filled with the shadow byte indicating that that thread can access all of it. Poisoning the redzones would have to be done still, but unpoisoning (and initial setup) would not set the shadow to zero(except for the main stack), but rather each byte (memset) back to (short_id << 3), which would indicate that the plugin with that short_id can read/write all corresponding bytes. * n-to-m mapping: If the stack is shared, it can...

I'm having trouble finding any documentation of the sanitizers, especially the leak checker -- apparently because of the move from code.google.com to github. Every doc has a link for "more information" which goes to code.google.com which just redirects to github and points to a placeholder doc that says lots of links are broken. I haven't found the docs using any google-fu or

On Mon, Nov 9, 2015 at 7:20 PM, Kostya Serebryany <kcc at google.com> wrote: > Most likely, you need > https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer Thanks! > I don't think lsan supports this mode directly, > but why do you think that the init-time allocations are going to be > "leaked"? > If there is some object still pointing to

On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > >Procedure of page migration is as follows: > > > > > >First of all, it should isolate a page from LRU and try to > > >migrate the page. If it is successful, it releases the

On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > >Procedure of page migration is as follows: > > > > > >First of all, it should isolate a page from LRU and try to > > >migrate the page. If it is successful, it releases the

+llvmdev, -llvm-dev On Tue, Jun 26, 2012 at 2:28 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Reid, > > On Tue, Jun 26, 2012 at 4:30 AM, Reid Watson <reidw at google.com> wrote: > >> Hello, >> >> I'm starting work on a project to detect initialization order problems >> in C++ files using AddressSanitizer. >> The extension in

...d plugins. > > * 1-to-1 mapping: > > Since the plugin owns the thread stack, all of the corresponding > shadow can be initially filled with the shadow byte indicating that > that thread can access all of it. > > Poisoning the redzones would have to be done still, but unpoisoning > (and initial setup) would not set the shadow to zero(except for the > main stack), but rather each byte (memset) back to (short_id << 3), > which would indicate that the plugin with that short_id can read/write > all corresponding bytes. > > > * n-to-m mapping:...

Hi everyone, I believe the ABI for exception unwinding on a stack tagged with MTE needs to be clarified -- hopefully we can start the discussion here? (Please feel free to add people to the thread that you think would be interested). I'll outline some possible approaches that I think seem good below, I know Evgenii and Peter have done a lot of investigation in this area for HWASAN, so

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use