On Tue, Aug 30, 2011 at 11:43 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2011-08-30 at 11:29 -0700, Javier Cardona wrote: >> Under failure conditions, the mesh stack sends PERR messages to the >> previous sender of the failed frame. This happens in the tx feedback >> path, in which the transmission queue lock may be taken. Avoid a >> deadlock by sending the path error via the pending queue. >> >> Signed-off-by: Javier Cardona <javier@xxxxxxxxxxx> >> --- >> net/mac80211/mesh_hwmp.c | 7 ++++++- >> 1 files changed, 6 insertions(+), 1 deletions(-) >> >> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c >> index fd4f76a..f760679 100644 >> --- a/net/mac80211/mesh_hwmp.c >> +++ b/net/mac80211/mesh_hwmp.c >> @@ -209,6 +209,10 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags, >> * @target_sn: SN of the broken destination >> * @target_rcode: reason code for this PERR >> * @ra: node this frame is addressed to >> + * >> + * Note: This function may be called from the tx feedback path, possibly with >> + * the transmission queue lock taken. To avoid a deadlock we don't transmit >> + * the frame directly but add it to the pending queue instead. > > I'd change that to say "with driver locks taken that the driver also > acquires in the TX path" or something like that maybe? OK > But that's not a big thing. Have you tested it? I'm wondering if because > we take a lock here we might run into lock dependencies issues (lockdep > would say) but I don't think so because stop_queue etc. all take the > same lock from an arbitrary driver context already. We don't have a test specific for that particular perr. Other tests run fine and lockdep does not complain. I can resubmit the patch with the clearer comment once we've run our whole test suite if that gives you peace of mind. Javier > Reviewed-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > > johannes > > -- Javier Cardona cozybit Inc. http://www.cozybit.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
