search for: unpoisoned

...see a better solution? 3) The return values include pointers into the object files. It seems perfectly reasonable for a user to want to read these object files based on information from dlinfo. That probably means we should unpoison them as well? Do we need to do something here 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?). Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/9...

...n values include pointers into the object files. It seems > > perfectly reasonable for a user to want to read these object files based > on > > information from dlinfo. That probably means we should unpoison them as > > well? Do we need to do something here 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 retur...

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))

...up) 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't be poisoned/unpoisoned back to a state readable by the next plugin using that stack space. When allocating stack variables, all corresponding shadow bytes have to be set to readable by that stack. Though it may be possible to have different stacks for each plugin, and use the same mapping as above. === What do...

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

...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't be poisoned/unpoisoned back to a > readable state. When allocating stack variables, all corresponding > shadow bytes have to be set to readable by that stack. Though it may > be possible to have different stacks for each plugin, and use the same > mapping as above. > > > === > > What do...

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