search for: unpoison

...d include dlfcn.h, but the interceptor file doesn't generally include system headers. What's the right thing to do here? 2) The structures pointed to contain linked lists, etc. of dynamic linker state. In order to avoid spurious failures, it seems like we should iterate the linked lists and unpoison all of them, but that seems expensive. Do you 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...

...t; sanitizer_platform_limits_posix.h and verify correctness with > assertions in .cc. > > > 2) The structures pointed to contain linked lists, etc. of dynamic linker > > state. In order to avoid spurious failures, it seems like we should > iterate > > the linked lists and unpoison all of them, but that seems expensive. Do > you > > see a better solution? > > Nope, sounds like that's want you need to do. > > > 3) The return values include pointers into the object files. It seems > > perfectly reasonable for a user to want to read these object...

...ss. In that case we should fix it the same as we are > fixing the failed migration case. I agree, it's a bug, although rare and non-critical. > Maybe it will be just enough to switch > the test_set_page_hwpoison() and put_page() calls? Unfortunately that restores the other race with unpoison (described below.) Sorry for my bad/unclear statements, these races seems exclusive and a compatible solution is not found, so I prioritized fixing the latter one by comparing severity (the latter causes kernel crash,) which led to the current code. > > And another practical thing is the rac...

...ss. In that case we should fix it the same as we are > fixing the failed migration case. I agree, it's a bug, although rare and non-critical. > Maybe it will be just enough to switch > the test_set_page_hwpoison() and put_page() calls? Unfortunately that restores the other race with unpoison (described below.) Sorry for my bad/unclear statements, these races seems exclusive and a compatible solution is not found, so I prioritized fixing the latter one by comparing severity (the latter causes kernel crash,) which led to the current code. > > And another practical thing is the rac...

...t page fault time. Soft offline is kind of mild/precautious thing (for correctable errors that don't require immediate handling), so killing processes looks to me an overkill. And marking hwpoison means that we can no longer do retry from userspace. And another practical thing is the race with unpoison_memory() as described in commit da1b13ccfbebe. unpoison_memory() properly works only for properly poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > (Also, which part prevents pages...

...t page fault time. Soft offline is kind of mild/precautious thing (for correctable errors that don't require immediate handling), so killing processes looks to me an overkill. And marking hwpoison means that we can no longer do retry from userspace. And another practical thing is the race with unpoison_memory() as described in commit da1b13ccfbebe. unpoison_memory() properly works only for properly poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > (Also, which part prevents pages...

...is race is a bug? It may turn a soft-offline attempt into a killed process. In that case we should fix it the same as we are fixing the failed migration case. Maybe it will be just enough to switch the test_set_page_hwpoison() and put_page() calls? > And another practical thing is the race with unpoison_memory() as described > in commit da1b13ccfbebe. unpoison_memory() properly works only for properly > poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. > That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > >> (Also, wh...

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

...the leak checker actually starts looking at allocations and which it checks. Ideally I would want to print the reports and only abort if its growing consistently or by more than some amount but that may not be necessary if I can track down where the growth is currently. 2) I want to use the poison/unpoison macros and function calls for asan and msan. However I haven't been able to find any documentation on this api. In particular msan and asan seem to have different thoughts on whether these functions should be called directly or through macros so I'm not sure which is the stable api. Also I...

...that the init-time allocations are going to be > "leaked"? > If there is some object still pointing to those allocations lsan will not > complain. Hm. That's a good point. I'm not exactly sure how the ripcord allocator being used in Postgres combined with the asan poison/unpoison calls would actually appear to lsan. But even aside from that I believe there are allocations that are made early in server initialization that are never freed and it's considered not worth the book-keeping to free them due to the on-off nature of the initialization. -- greg

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

...lobals in a > dlopen-ed library, or in any situation when we have multiple threads. > > > >> 2. Instrument all reads and writes in global initializers >> > > This has been fixed today (thanks Nick!) > > >> 3. After each TU's initializers run, we unpoison the shadow memory >> for all global variables >> > > Once we know what globals we need to poison, un-poisoning them is trivial. > > >> >> Note that once main has started running, AddressSanitizer will run >> normally. This will result in AddressSanitizer c...

...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 mappin...

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