Date: Mon, 5 Sep 2005 22:00:50 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Luigi Rizzo <rizzo@icir.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c Message-ID: <20050905180050.GB41863@cell.sick.ru> In-Reply-To: <20050905094341.A23343@xorpc.icir.org> References: <200509051602.j85G2Bpo090258@repoman.freebsd.org> <20050905094341.A23343@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 05, 2005 at 09:43:41AM -0700, Luigi Rizzo wrote: L> gleb, could you document how you are using the PRF_RUNNING L> and PRF_LEAVING flags that you added ? Ok, I will. Tomorrow or today. L> also i am unclear on whether there is a race condition involving L> unregistering poll (second part of netisr_poll()) L> while running the section of ether_poll() where it drops L> the mutex before calling the handler. L> L> ether_poll signals its activity with PRF_RUNNING, but L> netisr_poll() does not check it, so it might happen that L> L> 1. on one CPU, ether_poll() drops the lock before calling L> pr[i].handler(), perhaps even getting descheduled L> L> 2. on another CPU, netisr_poll() gets the lock and goes L> all the way to the end, setting pr[i].handler = NULL L> L> 3. on the first CPU, without further checks, the code L> tries to dereference the field. Yes, the race is possible and known to me, though I haven't triggered it. To fix it the plan is to turn polling off/on functionally, not on the next tick or on next interrupt. This idea has already been implemented in DragonFlyBSD. Since the race is not runtime one, and requires idle_poll to be enabled, which is not default setting, we can live with it. L> Also, what is the overall design - do you want to support multiple polling L> loops running concurrently (netisr_poll, one poll_idle per CPU, L> and possibly the poll_in_trap) ? The aim was to remove Giant from polling. When the polling was enabled we got a half-Giant-locked network stack - the receive part was all running with Giant. This does not fit into SMPng design and our statement that with debug.mpsafenet=1 the Giant is not used in network stack. With current design really we get a very small parallelizm in three threads: netisr, idlepoll, trap. This was not the main aim. The future plans have been described by Robert in his mail. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050905180050.GB41863>