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? 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. Reviewed-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> johannes -- 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
