Re: [PATCH] memory: Prevent array overflow in l1 page buffer pool.

On 9/19/16, 7:42 PM, "osv-dev@googlegroups.com on behalf of Nadav Har'El" wrote: >diff --git a/core/mempool.cc b/core/mempool.cc >index 50c938f..fad046d 100644 >--- a/core/mempool.cc >+++ b/core/mempool.cc >@@ -1099,9 +1099,12 @@ struct l1 { > } > static void* alloc_page_local(); >

Re: [PATCH] epoll: Bump the file reference count while polling.

On Fri, Sep 9, 2016 at 9:26 PM, Timmons C. Player < timmons.pla...@spirent.com> wrote: > There is a potential lock order inversion issue here. Closing > the file from the network side requires taking the file lock > after taking the socket lock. Conversely, polling a socket from > epoll takes th

Re: [PATCH] memory: Prevent array overflow in l1 page buffer pool.

Thanks for this patch. Looks serious, and I wonder if it explains https://github.com/cloudius-systems/osv/issues/755 Some comments and questions below. On Fri, Sep 9, 2016 at 8:12 PM, Timmons C. Player < timmons.pla...@spirent.com> wrote: > Under high levels of memory page churn, the array of pa

Re: [PATCH] tcp_input: net channel state fix

On 9/19/16, 5:23 PM, "Nadav Har'El" wrote: > >So what worries me is that if this netchannel hasn't been torn down for a > >reason - or being torn down in parallel - maybe it's not a good idea to >tear it > >down here. Or maybe there is a case where we "leak" netchannels (never > >tear them down

Re: [PATCH] tcp_input: net channel state fix

On Mon, Sep 19, 2016 at 4:37 PM, Player, Timmons wrote: > Well, KASSERT only actually fails in debug builds, so you’d never see a > problem with a release build > (since NDEBUG is defined in conf/release.mk). > So this patch looks like it is doing reasonable things to me, and I don't see a reaso

Re: Current State of C++ Unikernels

Interesting - thanks for the notes! I wouldn't read too much into the comparison slide - it was more of an overview slide. I think one of the areas the unikernel ecosystem at large is severely lacking in is education. Many of the people I talk to depending on their sets of communities they belong

Re: [PATCH] tcp_input: net channel state fix

I think I can answer a few of these. See answers inlined below… Timmons On 9/19/16, 8:53 AM, "Nadav Har'El" wrote: >I'm having a hard time understanding this patch. Maybe Avi (CCed) >remembers some of the code involved (which he wrote) and might have >better comments. > >Some questions inline

Re: [PATCH] tcp_input: net channel state fix

I'm having a hard time understanding this patch. Maybe Avi (CCed) remembers some of the code involved (which he wrote) and might have better comments. Some questions inline below: -- Nadav Har'El n...@scylladb.com On Fri, Sep 9, 2016 at 9:08 PM, Timmons C. Player < timmons.pla...@spirent.com> wr

[PATCH] sched: only allocate sched::thread objects on the heap

In issue #790, Timmons C. Player discovered something dangerous with on-stack sched::thread objects: The stack may be mmap()ed, so the scheduler now needs to access an application's mmap()ed memory area. Those accesses can potentially have all sort of problems (like page faults in the scheduler, if

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 01:30:15PM +0300, Nadav Har'El wrote: > On Mon, Sep 19, 2016 at 1:11 PM, Gleb Natapov wrote: > > > > So if I understand correctly, both your and Gleb's sentiment is there is > > no > > > need not to make the scheduler more forgiving for page table changes, but > > > rather

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 1:11 PM, Gleb Natapov wrote: > > So if I understand correctly, both your and Gleb's sentiment is there is > no > > need not to make the scheduler more forgiving for page table changes, but > > rather require that sched::threads objects live in a mapping which could > > nev

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 12:30:53PM +0300, Nadav Har'El wrote: > On Mon, Sep 19, 2016 at 11:55 AM, Avi Kivity wrote: > > > > > On 09/19/2016 11:49 AM, Nadav Har'El wrote: > > > > > > On Mon, Sep 19, 2016 at 10:52 AM, Gleb Natapov wrote: > > > >> > >> > 2. I'm afraid the scheduler thing might only

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 11:55 AM, Avi Kivity wrote: > > On 09/19/2016 11:49 AM, Nadav Har'El wrote: > > > On Mon, Sep 19, 2016 at 10:52 AM, Gleb Natapov wrote: > >> >> > 2. I'm afraid the scheduler thing might only be the tip of the iceberg >> of >> > problems caused by this lazy TLB thing. Coul

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 11:49:41AM +0300, Nadav Har'El wrote: > On Mon, Sep 19, 2016 at 10:52 AM, Gleb Natapov wrote: > > > > > > 2. I'm afraid the scheduler thing might only be the tip of the iceberg of > > > problems caused by this lazy TLB thing. Could we have, for example (and > > > this is j

Re: Lazy TLB flushing

On 09/19/2016 11:49 AM, Nadav Har'El wrote: On Mon, Sep 19, 2016 at 10:52 AM, Gleb Natapov > wrote: > 2. I'm afraid the scheduler thing might only be the tip of the iceberg of > problems caused by this lazy TLB thing. Could we have, for example (and

Re: Lazy TLB flushing

On Mon, Sep 19, 2016 at 10:52 AM, Gleb Natapov wrote: > > > 2. I'm afraid the scheduler thing might only be the tip of the iceberg of > > problems caused by this lazy TLB thing. Could we have, for example (and > > this is just a hypothetical example) one thread doing a write() to disk > of > > so

Re: Lazy TLB flushing

On Sun, Sep 18, 2016 at 10:37:22PM +0200, Nadav Har'El wrote: > Hi Gleb, I have a couple of questions (CCed to the OSv mailing list) about > your OSv commit 7e38453, maybe you remember something (or be reminded of > something when you look at the commit). > > This commit is apparently causing > ht

Re: Current State of C++ Unikernels

On Mon, Sep 19, 2016 at 2:10 AM, Waldek Kozaczuk wrote: > OSv has already a concept of module but I wonder if its core can be made > modular as well. For example there could be something like osv.base, > osv.io (osv.io.read, osv.io.write, etc), osv.net, etc I do not know > enough it it makes sen