Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 3 Apr 2020 19:54:56 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     linux-bluetooth@vger.kernel.org
Cc:     brian.gix@intel.com
Subject: Re: [PATCH BlueZ v2] mesh: Fix FPE in overcommit logic.
Message-ID: <20200403175456.cnw6dz4gywwq6xte@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org, brian.gix@intel.com
References: <20200331090400.18379-1-michal.lowas-rzechonek@silvair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200331090400.18379-1-michal.lowas-rzechonek@silvair.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Brian,

On 03/31, Michał Lowas-Rzechonek wrote:
> During overcommit, mesh_config_save is called in asynchronous mode to
> avoid blocking Send() calls. This means that update of cfg->write_time
> is scheduled via l_idle_oneshot, so if the next Send() gets scheduled
> first, the code may see elapsed time of zero.
> 
> If this happens, then the overcommit logic was already executed and the
> overcommit is pending, so we can just return.

Ping?

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND