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, 17 Jan 2020 15:36:40 +0100
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ] mesh: Offload loopback packets to l_idle_onshot()
Message-ID: <20200117143640.7erexoeo6bsevnky@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
References: <20200117071604.20675-1-brian.gix@intel.com>
 <20200117133402.jvnrhoect6olamtk@mlowasrzechonek2133>
 <E1B6E49B-2246-4C1E-9C3C-D15CA1B6DF9C@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E1B6E49B-2246-4C1E-9C3C-D15CA1B6DF9C@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 01/17, Gix, Brian wrote:
> > Hm. I can't seem to wrap my head around this backtrace. Do you maybe
> > have a reproduction path?
> 
> The backtrace doesn’t really show what has gone wrong very well,
> because what has happened is a heap corruption. The seg fault occurs
> during a memory alloc sometime later.
> 
> The physics of the problem, is best shown by local config client
> requesting segmented composition data from a local config server.  The
> one request, all response segments, the return seg ACKs all happen on
> the same C calling stack which gets *very* deep, and steps off the
> end, since nothing goes OTA. It does *not* happen during OTA
> operations because each discrete packet starts from a fresh C calling
> stack from main().

Yeah, I got that part - l_idle unwinds the stack so that everything
starts from the beginning, it'a pretty standard technique for main
loops.

What I couldn't find is the exact place where send_msg_pkt recurses, but
I think I've found it now, e.g. in this call chain:

    send_msg_pkt
    net_rx
    packet_received
    seg_rxed
    send_net_ack
    mesh_net_transport_send
    send_msg_pkt <- here

In the end: the patch is fine, but maybe change the commit log and/or a
comment, since, as you remarked, the backtrace doesn't explain much?

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